- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sun, 24 Feb 2019 00:12:22 +0100
- To: daniel.hardman@evernym.com
- Cc: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAKaEYhJ7k_F7Aws10UHf3O5GoO7XBzZxJwEWCqGf6GftsXfPtg@mail.gmail.com>
On Sat, 23 Feb 2019 at 22:53, 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. > Good suggestion Daniel. Tho that means it has to be cached somewhere or we have to create a resolver, and the libraries that go with it. Caching can also be another point of complexity. But I do agree in the longer term it's safer. However, my point is that strictly speaking, remote fetching is unnecessary, in the first place, so why force it at the spec level? > > 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! >> >
Received on Saturday, 23 February 2019 23:12:55 UTC