bkaptijn
commented
5 years ago 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.
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 = 1methodchar methodchar = %x61-7A / DIGIT specific-idstring = idstring ( ":" idstring ) idstring = 1*idchar 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 :
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.