RFC013 Verifiable Credential IRMA Proof Type
Last updated
Last updated
This RFC describes requirements for a Verifiable Credential Proof using IRMA signatures. It also specifies the requirements for Verifiable Credentials that support this proof type. An IRMA proof type acts as bridge between the IRMA ecosystem and Nuts ecosystem. Nuts uses DIDs, DID Documents and Verifiable Credentials as its base. Nuts node operators must trust specific DIDs. IRMA publishes public keys of its issuers on Github. By trusting that specific repository and by running the IRMA server, a Nuts node operator can trust all Verifiable Credentials signed by IRMA. Verifiable Credentials with an IRMA proof are still issued to DIDs but not issued by DIDs. The trust in the issuer is replaced by the trust in the IRMA ecosystem.
This document describes a Nuts standards protocol.
This document is released under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.
A Nuts network relies on trust. Verifiable Credentials only have value when their issuer is trusted. Without trusting any issuers, a Nuts node will just be a collection of identifiers and public keys. Not all desired issuers support DID and VC technology. Some of these trusted third parties do support the IRMA ecosystem. IRMA does not support DIDs and/or VCs but is capable of generating zero knowledge proof signatures. Using IRMA could therefore support adaption of Nuts until DIDs and VCs are widely accepted as the technology of choice. The IRMA ecosystem consists of a server and a mobile app. The existence of this mobile app makes it possible for a person to be in control of setting a signature. This is also needed since VC wallets are not yet widely available.
holder: The party that receives a VC from an issuer.
IRMA: I Reveal My Attributes.
IRMA credential holder: The IRMA user that issues a Verifiable Credential using the app on his phone.
issuer: The party that issues a VC.
implementing party: Organization or person that creates software that adheres to the Nuts specs.
proof: Proof asserting that a VC is valid using cryptography.
VC: Verifiable Credential according to the Verifiable Credential Data Model.
VP: Verifiable Presentation according to the Verifiable Credential Data Model.
This RFC introduces a new proof type. Any Verifiable Credential type that supports this proof type MUST state this in the corresponding RFC. The proof type identifier is:
The credentialSubject part of the VerifiableCredential MUST have an id and the id MUST be a Nuts DID. The id contains the holder of the Verifiable Credential. Since the proof is unrelated to Nuts DIDs, the issuer MUST be the same as credentialSubject.id. Trust with this type of proof is not placed in a specific DID but in an IRMA issuer from a specific IRMA scheme. Any implementing party MUST state how different IRMA schemes are supported.
Other attributes in the credentialSubject MUST relate to attributes from an IRMA scheme. For example the irma-demo scheme contains the credential email issued by sidn-pbdf. This credential contains the attributes email and domain. All entries in the credentialSubject MUST follow the same hierarchy. It MUST be a JSON object and MUST contain the scheme, the issuer, the credential and attribute name. The email and domain attributes would be included as:
All attributes in the credentialSubject MUST also be part of the IRMA signature.
As stated at the beginning of this chapter, the type for the proof is NutsIRMASignature2022. The proof MUST also contain a proofValue. The proofValue MUST contain a base64 encoded IRMA signature. The proof does not contain a signature created with an assertionMethod key from the DID Document.
An IRMA signature is represented as:
This paper contains an explanation on how the cryptographic scheme works. The interesting bits for getting the data from a signature are the message, A, and a_disclosedfields. The message is used to relate the signatures and its attributes to a DID. This is the actual text the user has signed using the IRMA app. The A fields identifies which credential is used from the IRMA scheme. The a_disclosed field contains the actual attribute values. These values are base64 representations of big integers. Big integers are required for the cryptography to work. Underneath they contain strings, booleans, integers or enums. All the other fields are required to validate the authenticity of the signature.
The example signature from above will be base64 encoded when used in a Verifiable Credential proof:
Below is a complete example of how an Irma proof can be embedded in a Verifiable Credential:
The proofValue has been abbreviated for readability.
Verification of an IRMA signature MUST be done by an IRMA server instance. It's also possible for an implementing party to embed the IRMA go libraries. Verification is done as follows:
Verify IRMA signature using IRMA server (or embedded library), which returns the attributes contained in the IRMA signature.
Verify each attribute in credentialSubject against its counterpart in the IRMA signature:
Verify it's present in the IRMA signature
Verify the attribute's value exactly matches its value in the IRMA signature
Verify that message from the IRMA signature exactly matches the value of credentialSubject.id
The dot-delimited format of the attributes in the verification result can be extended as follows:
becomes
The last validation is to check if the message from the IRMA signature matches the value of credentialSubject.id.
The IRMA ecosystem has two different schemes: pbdf and irma-demo. The latter one is not intended for production since all private keys are published with the scheme. Any implementing party MUST ignore all signatures made with that scheme in production.
The contents of the schemes can be viewed on Github: pbdf and irma-demo
Although IRMA supports revocation for credentials, the revocation check is only applied during issuance. An IRMA credential revoked today will not invalidate any signatures created in the past. This means that a Verifiable Credential with an IRMA proof MUST adhere to the generic revocation definition stated in §4.5 of RFC011 - Verifiable Credentials. It's the responsibility of the IRMA credential holder to revoke verifiable credentials that could have been compromised. The IRMA credential holder can do this with a renewed, not revoked IRMA credential. The next paragraph contains a default revocation for a Verifiable Credential with an IRMA proof
VCs that are issued with an IRMA proof can be revoked by publishing the following transaction on the network:
Such a revocation transaction has the following requirements:
the issuer MUST match the DID of the issuer field of the VC.
the subject MUST match the id field of the VC.
a reason MAY be filled with a revocation reason.
the date MUST provide the date in RFC3339 format. From this moment in time the VC is revoked.
the proof MUST be a NutsIRMASignature2022 proof.
the IRMA signature in the proofValue MUST use the same attributes as the IRMA signature in the original VC.
The transaction MUST be published on the Nuts network. The content-type is application/vc+json;type=revocation
Nuts foundation
W.M. Slakhorst
Request for Comments: 013
Nedap
May 2021
