Re: DID identifiers have a dependency on w3id.org

This is definitely a use case where something like Hashlink
https://tools.ietf.org/html/draft-sporny-hashlink-02 would come in handy.

On Sat, Feb 23, 2019 at 5:34 PM =Drummond Reed <drummond.reed@evernym.com>
wrote:

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