Re: Goals and Requirements for DID Method Standardization?

Steve - that is definitely a question we run into with long lived VCs (of
which I can think of many in the supply chain world from permitting on
out).  Somewhat related to certificate transparency I think.

With regulatory data and audits of that data, we often also hit scenarios
where there may be years involved in holding, and knowing what did was
attached to which business entity at a given time can be really important.
If we cycle through public keys often, the history of public keys can get
quite long there...

Mike Prorock


On Tue, Nov 26, 2024 at 1:45 PM Steve Capell <steve.capell@gmail.com> wrote:

> Thanks Manu
>
> I agree 100% that there is no intrinsic need for a DID to be long lived.
> So long as I can link my DID to a trusted identity framework (see
> https://uncefact.github.io/spec-untp/docs/specification/DigitalIdentityAnchor for
> example) then I can churn through as many DIDs as I like
>
> The problem we encounter in UNTP is exactly the one you highlight - some
> VCs have a very long life.  In our case these are trade & industry
> credentials not personal ones.  Agri-food VCs are  typically only relevant
> for a few weeks (until the fresh food is eaten or processed into longer
> lived processed products but even then (apart from fine wines) it’s usually
> months. The construction industry on the other hand is interested in
> verifiable data throughout the lifetime of the built environment which is
> usually many decades.
>
> So the business problem is - what happens to the verification of a long
> lived VC when the underlying DID is gone ?
>
> Steven Capell
> Mob: 0410 437854
>
> On 27 Nov 2024, at 1:53 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
> On Mon, Nov 25, 2024 at 3:02 PM Steve Capell <steve.capell@gmail.com>
> wrote:
>
> 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 or
> government agency might need to “move” a DID without invalidating
> previously issued VCs
>
>
> Thank you, Steven, I've added your requirement here (and invite others
> to add theirs to the issue tracker):
>
>
> https://github.com/decentralized-identity/did-methods/issues/10#issuecomment-2500827870
>
> I do agree that your requirement is important, but possibly for
> different reasons:
>
> There is one perspective here where government agencies, or
> businesses, might not need long-lived DIDs. Their DIDs only need to
> exist as long as the refresh cycles on their VCs (which might only be
> a few years). There is a need for them to report their new DID to some
> sort of trust framework that verifiers use, but one could make the
> argument that government-based DIDs only need to last a few years (as
> long as their longest credential). So, maybe the need isn't as strong
> for government agencies, which have strong control over their domain
> and refresh cycles?
>
> Now, the reality is that government agencies will probably just go
> with did:web (or any other web-based DID Method) for now, because they
> know how to secure a website and it ticks all the security boxes for
> their IT teams. It's probably also true that most government agencies
> have had a web domain for as long as their agency has existed as a
> presence on the Internet (.gov domain has been around for ~41 years).
>
> However, I think the need is stronger for individuals, who live for
> ~70+ years. More specifically, it's important for individuals to be
> able to have pairwise and ephemeral DIDs (for privacy reasons), but
> it's also important for individuals to have long-lived DIDs for public
> personas (reputation). That is, for things like your social media or
> other web-presence profiles (LinkedIn, X/Twitter, BlueSky, Instagram,
> Mastodon, etc.). There are dangers here -- like, never use your public
> DID when you have some expectation of privacy in the exchange and
> don't know how the other party will use your identifier over the long
> term -- it's dicey, and I don't mean to downplay the concern there.
>
> In any case, all that to say -- yes, long lived identifiers are needed
> for long-lived credentials... but perhaps the need is greater among
> individuals (who don't have control over the lifetime of VCs issued to
> them) than among organizations (who do have control over the lifetime
> of the VCs they issue). Then again, organizations don't have control
> over the VCs issued to them by individuals and other organizations, so
> perhaps this has more to do with "public personas" vs. private ones?
> There is, of course, a counter-argument that we should not be using
> long-lived identifiers at all... but I don't know how you can ZKP
> yourself through life -- at some point, people want to refer to you in
> a long-lived social context... and they prefer to use long-lived
> identifiers when doing so.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>