Should update authorizations be DID Method specific? And other Authorization questions

[swcurran]

The peer method spec includes a non-trivial authorization mechanism for defining what keys can be used when updating the DID Document. It seems to me that should mechanism should be work across DID methods. Checking a couple of other DID Methods, that does not seem to be the case, but wondered about the thoughts on that. I'm thinking that because of the underlying storage, perhaps that is not possible, since it would seem to be related to the update mechanism - e.g. messages in this case, but other techniques with other methods.

Related:

• If the authorization are NOT supposed to be part of the DID spec, but rather part of the method spec., should the methods try to use the same mechanisms? E.g. should the sov and peer methods share the same authorizations model?
• If the authorizations differ by DID method, does that alter the claim that a peer DID can be converted to an on-ledger/other method DID easily? This would mean that at least the authorization mechanism would need to change. Are we assuming that would be a transform?
• Could you describe how the n-of-m authorization would work? Presumably, the sync_state message would have a proof with multiple signatures, and it would be up to the sender to collect the signatures. Correct? An example might be useful - or perhaps it's obvious.

Other minor issues noted while reviewing:

• In the 1.1.2 Advantages section:
  • They scale and perform entirely as a function of participants, not with any central or decentralized system's capacity.
  • Because they are not persisted in any central system, there is no trove to protect.
    • Kind of - you have a trove in your wallet.
• Typo: it then describes the deltas that it knows about, that have happened since.

[peacekeeper]

This has come up a few times in the past, my thoughts are:

1. Authorization of Update and also Deactivate operations is definitely method specific and can vary greatly between different methods.
2. Such authorization may or may not be expressed in the DID Document.

Think for example about Ethereum-based DID methods such as erc725. This DID method can make use of the full power of smart contracts to set potentially very complex authorization rules for who can update/deactivate DIDs. It would be very complicated to "map" the code of a smart contract into constructs inside the DID Document. And there wouldn't be much value in doing this, since the underlying ledger Ethereum doesn't natively process DID Documents, instead it uses its own built-in mechanisms for authorization anyway.

Now for DID methods that do natively understand DID Documents, it makes more sense to include authorization information inside the DID Document. For example did:v1 or did:peer or did:sov may natively process their own DID Documents to express authorization. In the case of did:v1, object capabilities are used. In such cases, I agree different DID methods could re-use certain constructs to describe authorization, rather than everyone re-inventing their own. Not sure though if that should happen on the spec level or by some community conventions.

[mavarley]

@swcurran , I can address one of the questions: If the authorizations differ by DID method, does that alter the claim that a peer DID can be converted to an on-ledger/other method DID easily? This would mean that at least the authorization mechanism would need to change. Are we assuming that would be a transform?

There will need to be a transform based on the destination DID method, as referenced in section 6; anchoring a peer DID may invalidate the peer DID altogether for the purposes of that relationship (or may not).

I think we want to keep the spec flexible on how peer DIDs are used, so although specifying some guidelines is good, specifying exactly how to anchor a peer DID for other methods is (I think) outside the scope of this spec. Also, I would not want to accidentally push a requirement on other DID Methods to spec how to perform an anchoring... something to consider carefully.

[swcurran]

Thanks @peacekeeper and @mavarley. Agree with all your points - I think I had pretty much gotten there as I wrote the original note, but the additional information is very helpful. I'll close the issue.