Allow DID methods without Update and Delete

[pelle]

Several light weight DID methods such as the secp256k1-did-resolver do not allow Update or Delete.

These methods are primarily intended as lightweight identities for IOT devices, temporary session identities that can intro with more permanent identities.

Change wording to allow lightweight DID methods without Update and Delete functionality

---

Preview | Diff

[msporny]

Hey @pelle, I'm supportive of your changes. I think we can simplify them by making Update and Delete optional by changing the "MUST"s for those features to "SHOULD"s instead. Waiting for feedback from others, and I'll bring this up at RWoT next week.

[msporny]

We should probably just make Update and Delete SHOULDs, not MUSTs.

[msporny]

I suggest we change "MUST" to "SHOULD", that'll be cleaner.

[msporny]

Again, we should change the "MUST" to a "SHOULD" and that would enable the sort of ledger that @pelle is noting. Not being able to do update/delete is a valid use case. We may also want to back off on the language wrt. the only implementation mechanism for DIDs being a blockchain... which is not true, star-topology federations, DHTs, IPFS, are completely reasonable ways to implement DIDs.

[peacekeeper]

I support this too, I can see use cases where you just want to be able to construct a trivial DID document from the data in the DID alone, without interaction with any target system.

[pelle]

@msporny @peacekeeper updated the language

[msporny]

Ping @talltree @ChristopherA @kimdhamilton -- RWoT discussion item, we just need to give people a heads-up on this to see if they're going to object before we pull this PR in (I doubt they will object).

[talltree]

I am NOT supportive of this change. Here's the comment I made in the DIF Slack: The primary purpose of a DID is to provide an abstraction over the key pair(s) that are associated with the DID. In other words, continuity for a digital relationship that will NOT break when the keys are changed. So, while it may seem interesting to use a public key as a DID, *it is not actually a DID if it does not support the DID operations in the spec*. That’s why those operations are MUSTs. My POV is that if a developer wants to use a public key as a one-time lookup value, call it something else, and write a different spec for it. Just don't call it a DID. Happy to discuss more at RWOT (although Pelle won't be there).

…

On Fri, Mar 2, 2018 at 12:16 PM, Manu Sporny ***@***.***> wrote: Ping @talltree <https://github.com/talltree> @ChristopherA <https://github.com/christophera> @kimdhamilton <https://github.com/kimdhamilton> -- RWoT discussion item, we just need to give people a heads-up on this to see if they're going to object before we pull this PR in (I doubt they will object). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLkTZHF-l_MPhpE7YM14I-LWBT00Eyhks5taairgaJpZM4SaPgJ> .

[peacekeeper]

(As a meta-point, yes DID spec issues should probably be discussed here and/or on the CCG mailing list, rather than in the DIF Slack).

On the subject, I remember at some earlier time there was talk about a DID method based on PGP keys, and I think there was some agreement this would be a good idea. I don't think this every materialized, but I wonder how it would have worked.

[pelle]

@talltree lets bring this up again at IIW. We will likely need this method and I can only expect others need something similar. I'm happy to call it something else, but it will be DID resolvable, so JWT's signed are interoperable. This spec change with @msporny wording makes the difference clear.

[talltree]

Pelle, I really wanted to discuss this at Rebooting the Web of Trust but we ended out having very little time to discuss open issues with the DID spec as everyone was working on the next higher layer, e.g., DID Auth, Verifiable Credentials, and the like. I did have one conversation with Markus about it. We agreed that the easiest way to distinguish an decentralized identifier that has no Update and Delete methods would be to give it a different prefix. Markus suggested CID (for cryptographic identifier). I would support including a definition of CID in the spec by essentially including one section entitled "CID: Cryptographic Identifiers" and simply defining that a CID meets all other requirements of a DID except it begins with "cid:" and does not have an Update or Delete method. Would that work?

…

On Sun, Mar 18, 2018 at 3:00 PM, Pelle Braendgaard ***@***.*** > wrote: @talltree <https://github.com/talltree> lets bring this up again at IIW. We will likely need this method and I can only expect others need something similar. I'm happy to call it something else, but it will be DID resolvable, so JWT's signed are interoperable. This spec change with @msporny <https://github.com/msporny> wording makes the difference clear. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLkTactJAhgYvUmozvpTQeU0-x-uYkCks5tftj-gaJpZM4SaPgJ> .

[dlongley]

@talltree & @peacekeeper,

We agreed that the
easiest way to distinguish an decentralized identifier that has no Update
and Delete methods would be to give it a different prefix. Markus suggested
CID (for cryptographic identifier).

This introduces a lot of questions for me.

Why would introducing another prefix be a good idea? Couldn't you distinguish whether or not update/delete were functional based on the method identifier? Is there a reason for needing to know this without knowing the method?

What if a method author wants to leave open the possibility for adding update/delete support later but doesn't want to force people to get new DIDs?

Why the prefix "CID"? Some DIDs are already CIDs -- it seems like this might introduce confusion.

It seems to me that we don't need to introduce any other complexity or potential confusion here -- and can just say DID methods "SHOULD" provide update/delete and leave it at that. That leaves plenty of room for DIDs not to support it. DID-method specific drivers in software that do not support update/delete can simply report "Not Implemented"/"Not Supported" errors if an update/delete is requested.

[talltree]

Dave, I understand your perspective, but let me argue the opposite: removing Update and Delete castrates the ability for a DID to be the abstraction of a key pair. It literally removes the abstraction. In the interests of helping us establish a clear, strong story about this new class of identifier, I feel pretty strongly that something that removes that abstraction should not be called a DID. It should be called something else that makes it clear it is not a DID. How do others feel?

…

On Mon, Mar 19, 2018 at 7:05 AM, Dave Longley ***@***.***> wrote: @talltree <https://github.com/talltree> & @peacekeeper <https://github.com/peacekeeper>, We agreed that the easiest way to distinguish an decentralized identifier that has no Update and Delete methods would be to give it a different prefix. Markus suggested CID (for cryptographic identifier). This introduces a lot of questions for me. Why would introducing another prefix be a good idea? Couldn't you distinguish whether or not update/delete were functional based on the method identifier? Is there a reason for needing to know this without knowing the method? What if a method author wants to leave open the possibility for adding update/delete support later but doesn't want to force people to get new DIDs? Why the prefix "CID"? Some DIDs are already CIDs -- it seems like this might introduce confusion. It seems to me that we don't need to introduce any other complexity or potential confusion here -- and can just say DID methods "SHOULD" provide update/delete and leave it at that. That leaves plenty of room for DIDs not to support it. DID-method specific drivers in software that do not support update/delete can simply report "Not Implemented"/"Not Supported" errors if an update/delete is requested. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLkTQyyaXRxsx5WuYfj3tZsYtUewLUxks5tf7s9gaJpZM4SaPgJ> .

[pelle]

@talltree I'm pretty sure there is some important subtlety that I don't understand yet. So I think discussing it in person with a white board is best.

I still don't see the requirement for Update and Delete, when the primary purpose is to lookup authentication material, not handle CRUD itself. Or is it perhaps that I've misunderstood? Anyway no need to reply here, we'll take it in person.

[dlongley]

@pelle,

I still don't see the requirement for Update and Delete, when the primary purpose is to lookup authentication material, not handle CRUD itself.

I think @talltree's argument is that if there is no way to rotate the authentication material (i.e. no "Update"), then there's no point in having the lookup system. Just have the identifier be the public key and then, since its authentication material can never change, there's nothing to look up.

A DID is an identifier plus the ability to rotate authentication material. This makes it an enduring, stable, and resilient identifier.

[cbruguera]

If I may share my "2 cents" on the matter:

Although I agree with @talltree on the actual purpose of DIDs (aiming to represent "enduring, stable and resilient identifiers") I also think "practicality beats purity", in which case there are evident real use cases for "simple DIDs", especially when dealing with networks such as Ethereum. A DID on such a platform might provide as much abstraction (and complex functionality) as needed if the proper on-chain and offchain architecture is in place, but also simplifications such as regarding a public key (or more precisely an ethereum address in this case) as a valid DID (even for short-term usage) are a valuable possibility to consider. After all, they are still identifiers and still decentralized. Leaving these cases out of the DID specs poses a limitation on compatibility, when just including those would give room for these simple methods to enjoy all the DID-related features of the ecosystem that is being developed.

It is my appreciation that the most important aspect of DIDs are the quality to serve as public identifiers whose ownership can be (cryptographically) proved, in wich case public keys fit accordingly as probably the most simple case of DID. Additionally, as already mentioned, this level of flexibility allow these simple methods to evolve or increasingly incorporate other complex functionality and/or abstraction layers even if starting as (or still allowing) simple public keys as the most basic case.

In relation to this, it occurs to me that (following the Ethereum network example) some methods could still provide delete functionality by means of a "revocation registry" smart contract where DID-addresses could be "self-destroyed", still being valid network addresses yet not valid DIDs according to their corresponding method. Again, future functionality can be added around simple addresses (or public keys) that eventually give place to deletion or update methods, but limiting these simple cases beforehand might unnecessarily restrict the applicability of decentralized identity, especially in this early phase.

Looking forward to know all other opinions on this regard.

[msporny]

I also think "practicality beats purity", in which case there are evident real use cases for "simple DIDs", especially when dealing with networks such as Ethereum.

Yes, and this is why I'm supportive of Update and Deactivate being SHOULDs instead of MUSTs for DID Methods. The Ethereum use case @cbruguera and @pelle raise is a perfectly reasonable use of DIDs.

[talltree]

I think this is one of those issues that will benefit enormously from a F2F whiteboard session at IIW. I will definitely volunteer to hold one on this there (probably Wed or Thursday when session time is not so crowded). Looking forward to it.

…

On Thu, Mar 29, 2018 at 7:59 AM, Manu Sporny ***@***.***> wrote: I also think "practicality beats purity", in which case there are evident real use cases for "simple DIDs", especially when dealing with networks such as Ethereum. Yes, and this is why I'm supportive of Update and Deactivate being SHOULDs instead of MUSTs for DID Methods. The Ethereum use case @cbruguera <https://github.com/cbruguera> and @pelle <https://github.com/pelle> raise is a perfectly reasonable use of DIDs. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLkTfLx6jhlwxW_7EVBjvYW5hSTniCzks5tjPa-gaJpZM4SaPgJ> .

[msporny]

change to something like: MUST specify how an update operation can be performed or that updates are not possible.

[msporny]

The DID Task Force decided to merge this on 2019-08-01 after a call to merge (and with @msporny's change), there were no objections.

[rhiaro]

The spec had changed so much since this PR went in I couldn't rebase or cherrypick. New PR at #243 makes the same edits as @pelle, plus @manu's modification at the end of this thread.