- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sat, 23 Feb 2019 18:57:17 +0100
- To: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAKaEYhKrk6+o5RXgyEzqeKzLuhyizBQR0X7wVjC_P8ZYAttMHQ@mail.gmail.com>
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 17:57:51 UTC