L. Boldrin

1. Ledger role in SSI --- notes for discussion L. Boldrin

2. The mainproblemaddressed by SSI how to transfer trusted information about a subject between an issuer and a verifier while keeping ownership of data?

3. Solution based on Verifiable Credentials • Faber University register its DID and credential definition on the ledger • Faber University prepares a VC with the information on Alice • Faber University signs the VC with the private key associated to its DID • Faber University transmits the VC to Alice • Alice stores the VC in her personal store • When requested, Alice forwards the VC to Acme (ignore proofs for simplicity) • Acme detects the issuer (“issuer” field in the VC, probably a DID), • and gets the public key from the ledger to check the signature. • Acme only knows the DID of the issuer but has no clue on its real-world • identity. • Acme can also check from the ledger whether the VC has been revoked • from the issuer. • Acme needs some external information (Domain specific trust framework – to some extent supported by the ledger?) to understand the real-world identity of Faber (and its trustworthiness?). Domain specific Trust Framework Trust framework authority 8 Faber University Acme Hospital Alice 6 4 2 5 VC VC 7 Digital Wallet to hold credentials 3 Write: Public DID Cred Definition Revocation Register Read: Issuer DID Cred Definition Revocation Register VC 1 ledger ledger

4. The infrastructure I’m a doctor. Yep, you’re a doctor. X You’re now a doctor. Trust infrastructure Doctors Licensing Authority ledger Domain specific trust framework

5. A differentsolutionbased on Digital Signature (the EU model) • Faber University gets a signing certificate from a CA enlisted in a trust list • Faber University prepares a document (xml, pdf) with the information on Alice (e.g., university transcript) • Faber University signs the document with a digital signature (pdf sig, XMLDigSig…) • Faber University transmits the document to Alice (via e-mail or whatever) • Alice stores the signed document in her personal store • When requested, Alice forwards the signed document to Acme • Acme checks the signature and detects that the document is signed by “Faber University”. • The signature contains Faber’s certificate, so Acme can check the validity of the • signature. • Acme can trust that the signer is indeed “Faber University” since Faber certificate is trustworthy, because it has been issued by a CA on some trust list • NB: Acme has no information on the fact that Faber is trustworthy. Trustworthiness is achieved through non-technical mechanisms, like legal liability in a regulated context (If Faber signs something false, knowing its real-world identity, Acme can pursue it according to the applicable law). EU Trust Framework CA EU Trust List Faber cert 1 8 Faber University Acme Hospital Alice 6 4 Doc for Alice 2 5 Doc for Alice Faber cert 7 Faber cert Digital Wallet to hold credentials 3 doc

6. The infrastructure I’m a doctor. Yep, you’re a doctor. X You’re now a doctor. Trust infrastructure Doctors Licensing Authority CA Trust List CA CA enlisted in

7. Comparison The VC solutionoffers the following additional features

8. 1. subject confirmation In the digital signature model this is not native. Bob can send Acme a “university transcript” about Alice (this reminds of the “token-bearer” saml concept). This feature be achieved with the digital signature, by adding an authentication process. ACME must be able to verify that the person authenticating is the subject of the signed document, e.g. inserting a subject’s public key in the signed document (“holder-oh-the-key” method). In practice, however, authentication and document signing are two distinct and independent processes. Authentication and the signed document are bound by an identifying attribute (SSN, name/surname, ….) which is present in the signed document and is made available by the authentication. This feature does not require a ledger, as far as the Identity Owner can cryptographically proof that she is the subject of the VC.

9. 2. anonimity/pseudonimity As a direct consequence of the previous point - identifying attribute (SSN, name/surname, ….) which is present in the signed document - digitally signed documents need to include some identifying attributes – no anonymity/pseudonymity. In some contexts this is not an issue (e.g., bank onboarding).

10. 3. public issuerskey/metadata Digital signature allow for the inclusion of a certificate associated to the signing key. The certificate contains issuers metadata, including the public key. European standards XAdES, PAdES, CAdES make this information (either in KeyInfo or in CertificateValues tag) required. Doc for Alice Faber cert

11. 4. credentialrevocation • In the digital signature model, the signer cannot revoke a signed document. It can only revoke its signing certificate, but this has no effect on documents signed before revocation. Revocation of the certificate will only invalidate all the documents signed after the revocation. • This is possible using X503v3 Attribute Certificates, but they never found widespread adoption. • The need for credentialrevocationisnormallybypassed by: • Stating an «expiryperiod» of the credential (e.g., mydrivinglicenceexpires in 1/2024) • Providing instantaneousattestations (e.g., you are a hospitalized in this hospital today)

12. 5., 6. other utility funcitons Credential templates: Credential templates are valuable; however, they don’t necessarily involve a ledger. Payments: May provide benefits over off-ledger payments

13. Comparison: summary

14. Luca.boldrin@infocert.it