How to represent verification relationships? about did-method-dns HOT 2 OPEN

I am no expert, but here is my opinion:
some application developers might assume that did controllers/users will create dids that only allow for the verification method relationships that the controller/user wants the application to be able to use.

ex: if an application sees that a did contains a key for assertionMethod it might assume it can use it to assert statements the controller/user did not want to assert. the controller/user might not have explicitly asked the application to perform that operation but the application might do it because it thought the user implicitly asked for it.

for that reason I'd like it that all verification method relationships were explicitly stated in dns record(s) so that a user/controller can create a did that is only valid for specific operations.
that would reduce the possibility of a mismatch between what the did creator thinks of how the did will be used vs how the app will actually use it.

from did-method-dns.

I'd like it that all verification method relationships were explicitly stated in dns record(s) so that a user/controller can create a did that is only valid for specific operations

I agree, it's useful if DID methods let you control the verification method relationships in the DID document, so that the user/controller can specify which verification methods can be used for which purpose, however see below....

ex: if an application sees that a did contains a key for assertionMethod it might assume it can use it to assert statements the controller/user did not want to assert

I think this would be a very bad application that is malicious or not programmed correctly. If a key has an "assertionMethod" relationship, then this only means that the key may be used for asserting statements, but it doesn't mean that an application should do any such thing without an explicit user action. Such an application shouldn't have access to the user's private keys in the first place.

from did-method-dns.