Re: DID methods as W3C standards - a happy compromise?

On Tue, 22 Feb 2022 at 09:06, steve capell <steve.capell@gmail.com> wrote:

> Hi all,
>
> I've been delving into dozens of DID methods because I need to make some
> recommendations for customer decisions shortly.  I am starting to see
> patters and forming my own opinions on which DID methods might make sense
> for what purpose and which are likely to be well governed stayers which are
> (in my opinion - sorry) largely irrelevant.
>
> In doing so, I started thinking about the objections to the DID
> specification which seem to revolve largely around some desire to constrain
> the plethora of methods.
>

The objections IMHO are not very well articulated, but there's an FAQ here:

https://www.w3.org/2019/did-wg/faqs/2021-formal-objections/

I do agree with your point about the plethora of methods.  I personally
find it much easier to get behind the DID Core work, than I do to get
behind the DID method registry


>
> It's clear to me that W3C can't really prefer this or that blockchain or
> DLT implementation over another when it comes to developing standards
> without implying some kind of commercial preference.  Therefore leaving it
> to the market to propose a heap of DID methods and letting natural market
> consolidation choose the winner(s) seems the only way forward.
>

I think if you leave it to the market, it may remain as a reject, because
the method registry will only be as strong as the weakest link.  Which
includes legal question marks.


>
> However there are some (very few) did methods that clearly have no
> relationship to a specific technology and so can logically be separated out
> from the soup of "please use my ledger, it's better" methods as candidates
> for full W3C standardisation as part of the DID specification.
>
>    - did:key
>    - did:web
>    - did:dns
>    - did:ipid
>    - did:peer
>    - did:schema
>    - and maybe did:keri, did:onion, ..?
>
>
I could largely get behind that set, as a compromise.  But the challenge is
to please everyone in the method registry, and to please the W3C membership


> It would even be possible to have a decision tree to help users decide
> which of these ledger agnostic methods is good for what purpose.  eg if you
> are a government agency or a large corporate with well known and stable
> domains then maybe did:web is good for the credentials you issue.  If the
> subject of the credential is a short lived thing like a trade consignment,
> maybe did:key or did:ipid is the ideal choice.  If you are a small business
> or citizen that wants to protect your privacy but also be able to prove
> your identity or entitlement as the subject of (say) a government issued
> credential, then perhaps did:kerri would work well.
>
> Anyhow - the questions is - can't we pick just a small number of
> un-controversial methods to standardise?  even if it's just did:key and
> did:web to start with.
>

+1 to this proposal FWIW


>
> just a thought...
> --
> Steve Capell
>
>