Re: DID identifiers have a dependency on w3id.org

On Sat, 23 Feb 2019 at 23:45, Dmitri Zagidulin <dzagidulin@gmail.com> wrote:

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

Regarding just the integrity check, doesnt it also mean that you have to be
watching the dependencies such as

https://w3id.org/security <https://w3id.org/security#>

Again note the redirect.  What if that changes?  Are we going to use
hashlinks for those vocabs too?

Seems like a can of worms, but I am sure solutions can be found.  Just that
they seem complex?


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