How to support verifiable credentials exactly

[bkaptijn]

Might require changes in discipl core though we try to make this entirely to implementation of connectors.

[bkaptijn]

The proposal within the Waardepapieren project is that connectors use a common subconnector (discipl-core-node, though configurable) to hold a claim and attestation and provide in connector specific methods to issue the claim-attestation pair as a verifiable credential in a wallet. The ssid of the subconnector platform is used for signing.

We will first implement this in the discipl-core-paper connector that enables one to issue such a credential into a QR code that can be printed on paper (or stored in image etc). All other connectors to verifiable credential platforms should be implemented in similair fashion

[bkaptijn]

After discussion:

we are going to add methods to core and base-connector that can translate the discipl linked data exports to W3C verifiable Credential compliant (https://w3c.github.io/vc-data-model/ version 1.0 Editors Draft of 15 january 2020) verifiable presentations.

An export like:

{ "link:discipl:nlx..." : { "did:discipl:nlx..." : { "is" : "something", "approves" : { "link:discipl:ephemeral...B" : { "did:discipl:ephemeral...B" : { "toHave" : "that" } } } } } }

must be translateable into :

{ "@context" : "https://www.w3.org/2018/credentials/v1", "type" : "VerifiablePresentation", "verifiableCredential": [{ "type" : "VerifiableCredential", "id" : "link:discipl:nlx...", "credentialSubject" : { "id" : "did:discipl:nlx...", "is": "something", "approves" : "link:discipl:ephemeral...B" }, "issuer" : "did:discipl:nlx..." "issuanceDate" : "2010-01-01T19:23:24Z" "proof" : { "type" : "RsaSignature2018", "created": "2019-08-23T20:21:34Z", "jws":"RyJ0eXAiOiJK...gFWFOEjXk", "discipl-software-version-info" : {"nlx":"0.4.0"} } },{ "type" : "VerifiableCredential", "id" : "link:discipl:ephemeral...B", "credentialSubject" : { "id" : "did:discipl:ephemeral...B", "toHave" : "that" }, "issuer" : "did:discipl:ephemeral...B" "issuanceDate" : "2010-01-01T19:23:24Z" "proof" : { "type" : "Ed25519Signature2018", "created": "2019-08-23T20:21:34Z", "jws":"eyJ0eXAiOiJK...gFWFOEjXk", "discipl-software-version-info" : {"ephemeral":"0.11.0"} } }], "proof" : { "type" : "DisciplLink" "discipl-software-version-info" : {"core":"0.12.0"} } }

Each link within an export is interpreted as the id of a verifiable credential. The subject being also the issuer (so as well as being the subject id within the credentialSubject). The tree structure of nested verifiable credentials are transformed into a list of them. Each verifiable credential has a proof attribute that either is provided by the connector conforming official proof methods (https://w3c-ccg.github.io/vc-extension-registry/#proof-methods) if implemented otherwise defaults to a generic DisciplLink proof method type and always refers to the discipl software version of the connector the discipl link refers to. The verifiable presentation has such a default proof attribute denoting the core version used to generate the export.

For this, the core API must include methods:

getProof(link) : returns a LD Signature type of proof exportVerifiablePresentation(link, [depth], ...), like exportLD, but returning the verifiable presentation as above and a (probably not yet implemented) importVerifiablePresentation for which a separate issue is to be opened

at least the following optional method should be added to the base connector to support this:

getProof(id)