Re: DID Formal Objection Status Update (Dec 2021)

Hmmmmm

On Dec 20, 2021, at 04:25 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> So my thought process was as follows:
> 
> 1. did:method: ## this is a sub protocol 
> 2. did:method:name ## this is a name space within the sub protocol
> 
> Let's compare with:
> 
> 1. http:  ## this is a protocol
> 2. http://mycorporation <http://mycorporation/> ## this is a name space with in the protocol
> 


I would say, rather, starting with the well-known --

1. http: ## this is a URI scheme, which often but does not always 
         ## map to a protocol, and which one's browser and/or OS 
         ## usually maps to a handler/helper app (sometimes with 
         ## help from the user)

2. http://example.com ## this is a namespace within the scheme

3. http://example.com/index.html ## this is the stuff within the
                                 ## namespace within the scheme

Yes, http: maps rather to the HTTP protocol, but they are not the 
same, and blurring such lines is how we get into very deep holes
as standard development proceeds.

Then, *after* covering the long-used if not as well-understood as
we might wish, I would suggest moving to the new thing we're working
to explain and understand as we go ... which I'm not going to try to
explain at this hour in my time zone.


> So the idea is that (1) something that is a protocol or sub protocol, in my mind should be a technical spec, non-proprietary, open
> 
> And that (2) could be also proprietary, a per company things, for profit etc.
> 
> As we see with http and the web, that's how it works, http is neutral and any company can have a web site.  It's a system that works well

The URI format is open, being RFC-specified.  URI schemes and
formats are not necessarily open -- and there's no requirement
that they be so! -- nor that the scheme even be registered -- 
though not registering a corporate-confidential scheme and format
*might* lead to collisions on the open web, so long as there's 
some cleverness by that tech team, little meaningful information
should be leaked by such...

The DID scheme, and the basic DID URI format, are open, being W3C-REC
specified.  DID methods, and the format beyond the first colon, may be
mostly if not entirely proprietary.


> With DID's it seems that things are more mixed.  Some of the sub protocols or methods in the registry are proprietary security tokens with the aim of monetizing the protocol
> 
> It would be good to clarify the extent to which did methods can be neutral decentralized protocols, vs centralized, proprietary and monetizable 

DID methods *may* be virtually if not entirely proprietary and
monetizeable -- but this will have some effect on how they get
evaluated through the rubric, which may lead to low (or high, 
who can predict these things?) uptake in the general marketplace.

Decentralized IDentifiers would seem to me more valuable if they
were less proprietary and more open, in all the ways those words
might be understood -- but I cannot make this judgement for all
in the world, especially as there may be other valuable factors
which some proprietary specifier and/or implementer delivers to
their users, which those users prize more highly.

That's the open market for you!

Be seeing you,

Ted



--
A: Yes.                          http://www.idallen.com/topposting.html
| Q: Are you sure?           
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         20 Burlington Mall Road, Suite 322, Burlington MA 01803
     Weblog    -- http://www.openlinksw.com/blogs/
     Community -- https://community.openlinksw.com/
     LinkedIn  -- http://www.linkedin.com/company/openlink-software/
     Twitter   -- http://twitter.com/OpenLink
     Facebook  -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers