Make usage of DID compliant to specification draft v0.11 (as much as disirable)

[bkaptijn]

the spec: https://w3c-ccg.github.io/did-spec/#decentralized-identifiers-dids

Our did identifier syntax seems already compliant:

did:discipl::

as long as pubkey only contains characters: ALPHA / DIGIT / "." / "-"

---

Note that we include the pubkey in the did used when creating the ssid on the supported platform. If we'd resolve this did to a sufficient did document it would just become:

{
'@context' : 'https://w3id.org/did/v1'
'id' : 'did:discipl:-'
}

we will just use the did value within discipl core; for now this seems enough. A DID method etc should be specified per platform supported.

Why are we using discipl as method that wraps platforms that define their own DID methods? Because we think the DID specification is already way too complex. It includes many key observations that we do agree with however: bind did's to platforms / cases, caution about herd privacy, linkabillity between dids etc. We want to comply with it as far as we are at ease with

Note: for now we do not use did references as long as the did is the only information we hold in a DID document under the discipl scheme. this may change in the future

discipl is a sort of meta DID scheme. We therefore should describe somewhere :

... a DID method specification MUST specify how each of the following CRUD operations is performed by a client. Each operation MUST be specified to the level of detail necessary to build and test interoperable client implementations with the target system. Note that, due to the specified contents of DID Documents, these operations can effectively be used to perform all the operations required of a CKMS (cryptographic key management system), e.g.:
Key registration
Key replacement
Key rotation
Key recovery
Key expiration

Create
The DID method specification MUST specify how a client creates a DID record—the combination of a DID and its associated DID Document—on the target system, including all cryptographic operations necessary to establish proof of ownership.
Read/Verify
The DID method specification MUST specify how a client uses a DID to request a DID Document from the target system, including how the client can verify the authenticity of the response.
Update
The DID method specification MUST specify how a client can update a DID record on the target system, including all cryptographic operations necessary to establish proof of control.
Delete/Revoke
Although a core feature of distributed ledgers is immutability, the DID method specification MUST specify how a client can revoke a DID record on the target system, including all cryptographic operations necessary to establish proof of revocation.

… NOTE:

did-reference = did [ "/" did-path ] [ "#" did-fragment ]
did = "did:" method ":" specific-idstring
method = 1*methodchar
methodchar = %x61-7A / DIGIT
specific-idstring = idstring ( ":" idstring )
idstring = 1idchar
idchar = ALPHA / DIGIT / "." / "-"

we append to this:

platform = 1idchar
pubkey = 1idchar

this last thing may be an issue when using large keys. IOTA uses 81 character sequences that comply with this.

We could add a resolveDID(did, pkey) that resolves a given did:discipl :

• verifies existence of the DID with or without giving a pkey(though if you provide the pkey, it may be considered to exist implicitely).
• authenticates the DID with the pkey without adding information to the channel

We could add a getDIDDocument(ssid)
that returns a formal json-ld DID Document compliant with the spec, as internally we do not use such objects.

[bkaptijn]

A minimal credential like one in the waardepapieren project conforming to the latest W3C v0.13 draft would be:

{
"@context": "https://www.w3.org/2018/credentials/v1",
“id” : "link:discipl:ephemeral394799234772934879324...",
“type” : ["VerifiableCredential", "Uittreksel-GBA-woonplaats"],
"issuer" : "did:discipl:nlx2349837EF9032783278CD93434..."
"issuanceDate" : "2017-01-01T19:23:24Z"
"credentialSubject": {
"BSN" : "123862327"
"CityLivingIn" : "The Hague"
}
}

Instead of the id property (which is optional) we could store the signature to test in a proof property. Discipl seems to introduce usage of "linked verifiable claim data exports" as the contents of the credentialSubject and which already includes links and as such the signatures that can be used to validate the exported data which are encoded into them and removing the need for any other property than just this export. This calls for a paper to be discussed in a RWOT event.

[bkaptijn]

Also relates to updated issue #6