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

Another issue with this approach :

"EquihashProof2017": "sec:EquihashProof2017",
"GraphSignature2012": "sec:GraphSignature2012",
"IssueCredential": "didv:IssueCredential",
"LinkedDataSignature2015": "sec:LinkedDataSignature2015",
"LinkedDataSignature2016": "sec:LinkedDataSignature2016",
"RsaCryptographicKey": "sec:RsaCryptographicKey",
"RsaSignatureAuthentication2018": "sec:RsaSignatureAuthentication2018",
"RsaSigningKey2018": "sec:RsaSigningKey",
"RsaSignature2015": "sec:RsaSignature2015",
"RsaSignature2017": "sec:RsaSignature2017",

Look at all these year specific references.  That indicates that the vocab
is likely to change at least once a year.  Put your URIs inline and it's
not a problem.  But for everyone else, it's going to be a whole update
process, possibly twice a year to start with.  And cache invalidation.
Then communicating to all the implementations that need it the change.  And
also what happens when one hash changes to another (also the hash of what
exactly!)?

None of this is necessary if you put URIs inline, and the documents are
canonically the same.  Existing producers of linked data, that want to can
start playing with the technology immediately.  Thoughts?


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