Re: DID Method Registry Needs Private-Public and Purpose Columns? [Was: Re: Fwd: New member - and (hopefully) an interesting use case - and a question]

Certification and filtering are both... political questions, fundamentally,
as no one  wants to be the one responsible for centralizing the
decentralized identity landscape. I'm not the best person to provide a
thumbnail history of how this discussion has been simmering along for the
last two years, but I _DO_ like (and +1) the idea of making "what happens
next with the Decentralization Rubric project and broader Method-selection
debate" into a "stump issue."  Would Heather and Joe care to speak to how
they see this question in the priorities for the group over the next two
years?

Cheers,
__juan

On Thu, May 28, 2020 at 12:54 AM steve capell <steve.capell@gmail.com>
wrote:

> I suppose it's stating the obvious - because Steven references my question
> - but I'd certainly be in favour of adding information to the registry that
> helps users (ie implementers) know how to navigate it.
>
> also, not sure whether this is allowed within W3C governance rules - but
> some kind of implementation / uptake count and feedback mechanism could be
> helpful.  As a newbie my review of this list would apply 2 filters:
>
>    1. which of these is the right functional fit for my needs?  - the
>    columns suggested by Steven will help a lot with that.
>    2. which of the ones that claim to fit my needs have some evidence of
>    uptake?  if at least one independent organisation other than the publisher
>    has successfully used the publishers method then that gives me some
>    confidence.
>
> I suspect if I could scan that list to answer those two questions then I'd
> probably zero in on two or three out of 60 and the proliferation problem
> would sort itself out very quickly.
>
> kind regards,
>
> On Thu, 28 May 2020 at 02:05, Steven Rowat <steven_rowat@sunshine.net>
> wrote:
>
>> On 2020-05-26 8:31 pm, steve capell wrote:
>>
>>
>>
>>    1. the method part of the DID is important for interoperability and,
>>    although I can see the value in letting anyone setup a new method, there is
>>    a risk of explosion - as
>>    https://w3c-ccg.github.io/did-method-registry/ seems to already
>>    show.  Looking at this list of methods, I really have no idea what problem
>>    each is solving, why there are so many, and whether I should re-use one or
>>    create another.  I'd be keen to discuss that problem with someone!
>>
>>
>> +1
>>
>> It seems it was only yesterday there were 6 entries in the DID Methods
>> registry, and now there are 59.
>>
>> I believe developers (as well as outsiders with general interest about
>> what's happening here) will want a way to easily sort this list for
>> purposes, either to find someone to contract, to know whether to start one
>> from scratch, or to know if a FOSS Method is already in development for a
>> given purpose.
>>
>> So:
>>
>> I'd like to propose adding either one or two columns to the Method
>> Registry. If two columns are possible, perhaps the first might say one of
>> three things:
>>
>> Private Internal / Private for Public Use / Public Free Open Source
>>
>> And the second column, beside that, is a brief description (one or two
>> sentences) about what it does. IMO the "Private Internal" case wouldn't
>> need to enter a description, but the other two would need to do so.
>>
>> If something like this was done, it would be relatively easy to scan the
>> list and see which methods are of interest and contact the relevant
>> developers to see the status. Otherwise, with 59 (and maybe hundreds soon?)
>> it will be a herculean effort to try to figure out what exists already and
>> what needs to be done.
>>
>> And also, since the election is upcoming, I'd like to know if any of
>> those running for Chairs of the group would agree that something like this
>> should be done.
>>
>>
>> Steven Rowat
>>
>
>
> --
> Steve Capell
>
>

-- 
-----------------
Juan Caballero
Communications & Research Lead, Spherity.com
Berlin-based: +49 1573 5994525
Signal/whatsapp: +1 415-3101351