DID identifiers have a dependency on w3id.org

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