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

Thanks for the pointer.  This is also a pretty good spec, imho.

However this actually doubles the pain.  Not only do I have a round trip to
deal with, again what if the central site is down, or the redirect is down?

But now not only must I fetch the remote context asynchronously, but I also
have to perform an integrity check -- and this is alot more complex than
Daniel's suggestion of SHT256 (for which libraries are wide spread),
because it uses multi hash and multi base requiring the writing and
debugging of another library.  Quite a headache!

To be clear in JSON LD the context is optional.  What the context allows
is, basically a short form of the keys in the JSON, so instead of writing
example.org/id I would write id, and so on.  Ultimately the pre processor
will translate the document into full URIs.

What I'm saying is that the problem goes away if you use full URIs as keys,
which my system has to do anyway.  Anything parsing the DID document would
get the exact same canonical form.  I think the implementation would pass
any conformance I think.  It's just quite time intensive in our system to
get patches upstream, and I could have the less strict version working,
more or less overnight.

So, what is the route for someone like me that wants to implemented the
ideas here, but just doesnt want to be constrained by the syntactic sugar.
I could create an "almost compliant" version, or would the group consider
making it easier for those that wish to put the URIs inline.  IMHO it's
actually easier to write out without a context.


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