Re: DID identifiers have a dependency on w3id.org

Another way to preserve the decentralization without doing inline contexts
would be to say, in the spec, that the URI could be a hash to a known
version of the spec, as in:
"sha256://C0BCA7A7C3D9CCFC15D99648D30BA61515970B47FCFB6611C7DD6DF1D21313CE"
(which is the sha256 of the JSON-LD file at https://w3id.org/did/v1). This
would let everyone verify that they are talking about the same thing, but
people could get the content anywhere.

What we should be dependent on is a particular chunk of json-ld content,
not a particular location where the content is published.

This is really just converting from URI to URN, and there are probably more
elegant ways to do it. It's the principle I'm suggesting, not the specific
method.

On Sat, Feb 23, 2019 at 10:58 AM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

> There seems to be a dependency in the spec in on w3id.org
>
> "The value of this key *MUST* be the URL for the generic DID context:
> https://w3id.org/did/v1"
>
> DID method specifications *MAY* define their own JSON-LD contexts.
> However it is *NOT RECOMMENDED* to define a new context unless necessary
> to properly implement the method. Method-specific contexts *MUST NOT*
> override the terms defined in the generic DID context.
>
> https://w3c-ccg.github.io/did-spec/#context
>
> I think it is all find and good for people coming new to the world of
> linked data.  But I am wondering about those who have a bit more experience
> and would want to use points of flexibility.
>
> So the w3id.org dependency could be seen as a central point of failure.
> Sort of ironic for a scheme with "decentralized" in its name.  What if the
> site is down?  Furthermore it's a redirect, which is a 2nd point of
> failure.  What if the content is changed?  This could have marked impacts
> on the integrity of ALL did documents.  Furthermore, the ambition to
> outlast the web being strictly tied to a web bootstrap is slightly odd.
>
> What I'd like to do rather is to put the context inline, which saves one
> round trip, and prevents those points of failure.  Additionally my
> preferred serialization would be turtle, for which you have to put imports
> (as in java imports) inline, rather than remotely, solving the problem.
>
> I like the idea of DIDs and the idea of putting a key in its own document
> is a compelling use case imho.  What should I do about these constraints?
> Could we soften the language from MUST to SHOULD.  I dont really want to be
> in willful violation of what I think is a pretty good spec, so advice is
> welcome!
>