Re: DID identifiers have a dependency on w3id.org

On 2/24/19 5:13 PM, Melvin Carvalho wrote:
> OK, that makes sense!  So w3id.org <http://w3id.org> is just a stop 
> gap.

In general, it's not a stop gap.

In the specific case of the Verifiable Credentials spec, and the DID
spec, it is there to support development and the final spec will use a
W3C hosted URL.

Note that this absolutely does not mean that there is centralization.
W3C is effectively providing an identifier under their domain. It is up
to implementations to determine what to do with that identifier. The
best practice at present, for production systems, will be to load a
static, permanently cached file from disk (JSON-LD implementations) OR
to hardcode your implementation against a very specific set of key-value
pairs (JSON implementations).

> Will this apply to all the dependent vocabs too such as "sec"

Yes, it will.

> And what about my point that new algorithms are added on a year by 
> year basis?  How does that match with the freeze for all time.

The expectation is that:

https://www.w3.org/2019/did/v1 will be frozen for all time.

A new URL will be created to do development:

https://w3id.org/did/v2.dev

Once that stabilizes (via a second WG), then the stable terms will be
placed in something like:

https://www.w3.org/2025/did/v2

and if there are v1 bug/security fixes, they will be placed in:

https://www.w3.org/2025/did/v1

This ensures multiple things:

* Implementations don't need to go out to the network.
* The context will never change out from under production
  implementations.
* JSON-LD people are happy because the semantics are properly defined.
* JSON people are happy because they don't have to use a JSON-LD
  processor if they don't want to, they can hardcode their semantics
  like they always do.
* We don't paint ourselves into a corner wrt. how future implementations
  can change. We could quite literally redefine *everything* in v2 and
  not break any of the v1 implementations.
* We don't need to use more complex content addressed URLs, but don't
  prevent others from doing so if they really want to do this.

> So how about those that have the same canonical form but want to use 
> full URIs, which save a round trip on top of all the other advantages
> I describe

I don't think the DID spec should prevent this. That said, we do need to
suggest at least one valid syntax in the spec. Based on how the VCWG
went, and how the WoT WG is going... as well as the new JSON-LD 1.1
work... it's most likely going to be JSON and JSON-LD (with statement
saying that semantically equivalent expressions in any other format with
a clear mapping to/from the data model are valid). Therefore, if someone
wants to express all of this in TURTLE, or N-Quads, or CBOR... that's
perfectly fine (as long as the mapping to/from is also defined).

> Will the spec allow this, or can we be in willful violation but 
> provide implementations that pass the test suite?

The test suite will probably test a JSON/JSON-LD expression of the data
model... but if your implementation can convert from your internal
format to/from JSON/JSON-LD, then that should pass the test suite.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Monday, 25 February 2019 14:11:37 UTC