Re: Goals and Requirements for DID Method Standardization?

This is a great point to add, and fits somewhere between a web based method
and a decentralized method as described. True portability is a very
difficult concept for me to conceptualize at the moment. I understand the
need, but the how I think is still very complicated to achieve.

On Mon, Nov 25, 2024 at 3:03 PM Steve Capell <steve.capell@gmail.com> wrote:

> 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/
> >
>
>