Re: DID identifiers have a dependency on w3id.org

+1 to Daniel's suggestion.

On Sat, Feb 23, 2019 at 1:54 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> 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!
>>
>