Drop id DID URI restriction

[OR13]

See #12 (comment)

We should add some of the learnings from the aries community on this topic to the spec, and allow for https uris, it will be easier to validate while the spec evolves, and of course any https uri can be converted to did uri using the service endpoint.

[decentralgabe]

I have some concerns for allowing https URIs, namely that in the context of the Workday system the ID is the URI. Meaning, you can resolve something like did:work:MDP8AsFhHzhwUvGNuYkX7T;id=06e126d1-fa44-4882-a243-1e326fbe21db;version=1.0 on our ledger and it will return you the schema.

I would advocate for requiring a schema identifier is unique. Putting it off a did helps with that, as the did controller could be useful in enforcing uniqueness under their prefix.

I am unfamiliar with the previous discussion and will need to do some reading.

[OR13]

https://github.com/snowplow/iglu-central/blob/master/schemas/com.snowplowanalytics.self-desc/instance/jsonschema/1-0-0#L15

I think we can allow for strict uri's or did uri's.

did uri's often rely on https uri under the hood via matrix params, so its helpful to be able to test without hitting a resolver as a proxy.

That being say, we could include SHOULD language to encourage the use of DID URIs.

[decentralgabe]

I have been reading over some of the Aries discussion.
I think the biggest question in my mind is: should the ID be a URI?

The Workday thinking has been the ID should first be an identifier (guaranteeing uniqueness, specifying authorship, and version), and second (or even third) be a URI. The ID could just be a UUID, but adding the did allows us to communicate some more information without having to resolve the document. The fact that the ID helps you resolve the schema is nice, but almost irrelevant -- to have the schema in the first place you would have needed to resolve it.

This allows us to separate the hosting from the identification of a schema. A schema with the same ID could be hosted in multiple places (i.e. have different URIs, but the same ID).

Maybe it's best to decouple resolvability and identification.

[OR13]

Certainly it is, thats why IPFS and content addressing is showing up all over the place.

However its handy to be able to refer to content in a number of different ways:

https://ipfs.io/ipfs/QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG/readme

ipfs:QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG

did:example:123456789abcdefghi;service=ipfs/QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG/readme

...
"service": [{
    "id":"did:example:123456789abcdefghi#ipfs",
    "type": "IpfsService",
    "serviceEndpoint": "https://ipfs.io/ipfs/"
  }]

See also: https://w3c-ccg.github.io/did-resolution/#examples

You can't just drop a did uri in a browser or curl it without prefixing it with something like:

https://uniresolver.io/1.0/identifiers/did:example:123456789abcdefghi;service=ipfs/QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG/readme

Which under the hood this would use:

https://ipfs.io/ipfs/QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG/readme

... but Im not actually sure if the content would be resolvable over http with today's universal resolver... certainly it would not work for any DID that did not have serviceEndpoint configured... which for public ledger DIDs could cost money and take a while.

Should everyone who wants to use vc-json-schema be required to create a DID and be able to update their serviceEndpoints to expose a service so the matrix param approach will work?

I'm all for adding strong language saying that the id SHOULD be a DID URI, but it seems needlessly restrictive to make it a MUST.

Are the DID URIs we are currently talking about resolvable using the universal resolver today?

This one does not currently work:

https://uniresolver.io/1.0/identifiers/did%3Awork%3AMDP8AsFhHzhwUvGNuYkX7T%3Bid%3D06e126d1-fa44-4882-a243-1e326fbe21db%3Bversion%3D1.0

[decentralgabe]

I'm all for adding strong language saying that the id SHOULD be a DID URI, but it seems needlessly restrictive to make it a MUST.

Definitely agree.

Are the DID URIs we are currently talking about resolvable using the universal resolver today?

For now, no. To start, we decided just to expose did documents and not other documents on our ledger.

Maybe it would be helpful to think of the ID as:
<author information>;id=<uuid>;version=<schemaver>

Certainly if the author information was a did it should be a URI and resolvable where the DID could be resolved.

Should everyone who wants to use vc-json-schema be required to create a DID and be able to update their serviceEndpoints to expose a service so the matrix param approach will work?

I don't think so, but it can be a recommendation.

[OR13]

Another consideration I thought of this morning is the fact that we are attempting to extend the VC Data Model, which is not restricted to DIDs alone. I think we have to account for the normal HTTP / non DID users of the VC Data Model.

@msporny @dlongley any thoughts on this?

[decentralgabe]

Handling in V2 branch -- #52