Re: Goals and Requirements for DID Method Standardization?

Hi Manu 

As mentioned in the previous message, maybe something about did portability 

Long lived VCs need long lived DIDs.  Domain names change, ledgers come and go, hosted DiD web issuers go bust, … lots of reasons why a business of government agency might need to “move” a DID without invalidating previously issued VCs 

Kind regards 

Steven Capell
Mob: 0410 437854

> On 26 Nov 2024, at 2:38 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> Hey folks,
> 
> The joint work on DID Method Standardization has begun. We had our
> first meeting[1][2] two weeks ago, with the next meeting to be held
> the week after this one. In the coming months, we will be gathering
> goals and requirements for DID Method standardization to determine
> which DID Methods we should try to standardize. We'll be looking to
> the broader decentralized identity communities to suggest what our
> selection requirements should be for the standardization work.
> 
> I'm going to try to provide a few examples (we'll probably do a ranked
> choice poll to rate the importance of each goal/requirement). Please
> add your own to this thread so we can include them in the community
> poll (which we'll probably run early Q1 2025).
> 
> Requirements for DID Method Standardization:
> 
> * At least one ephemeral DID Method should be identified for
> standardization. These are useful for short-lived, secure
> communication. Examples include did:key and did:jwk.
> 
> * At least one web-based DID Method should be identified for
> standardization. These are useful for issuers of verifiable
> credentials and other forms of attestations who know how to manage web
> domains but are not willing to depend on blockchains or DHTs for their
> root of trust (i.e., governments). Examples include did:web and
> did:tdw.
> 
> * At least one "fully decentralized" DID Method should be identified
> for standardization. These are useful because they achieve what the
> other two classes of DID Method above don't achieve -- the vision for
> why we created DIDs in the first place. Examples include did:dht.
> 
> * "Global government-approved crypto" is important to ensure
> governments can adopt the DID Method. Examples include ECDSA.
> 
> * "Privacy-preserving crypto" is important, even if not government
> approved, to ensure the privacy of individuals. Examples include BBS.
> 
> * A digitally signed cryptographic log of changes to the DID Document
> is a useful feature to standardize on its own (so that multiple DID
> Methods could utilize the feature).
> 
> * A multi-factor binding to DNS is an important feature to standardize
> on its own (so that domain owners can provide an extra level of
> security on their DID Documents).
> 
> * A specification with multiple implementers is always preferable to
> inventing something new unless the community is behind the concept
> that the "something new" is necessary.
> 
> I know I'm missing many more requirement ideas, so what are they? What
> do you feel we should include as requirements as we go through the
> selection process for which DID Methods (and their features) should be
> standardized?
> 
> -- manu
> 
> [1] https://lists.w3.org/Archives/Public/public-credentials/2024Nov/0026.html
> [2] https://lists.w3.org/Archives/Public/public-credentials/2024Nov/0035.html
> 
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>

Received on Monday, 25 November 2024 20:02:24 UTC