[OIDC4VCI] Holder Binding material without PoP

[Kristina Yasuda]

Do we know any use-cases that require sending a cryptographic identifier (e.g a did or public key) in the request without a PoP (Proof of Possession of that identifier like a JWS)? (In relation to PR #133)

[Tobias Looker]

I think there may be usecases for credentials that are not cryptographically bound to the requestor, however when they are a PoP should be required.

[Kristina Yasuda]

One such use case is Smart Health Cards, where an additional OAuth API is used to issue a signed credential, but without a holder binding

https://spec.smarthealth.cards/#via-fhir-health-cards-issue-operation

[Kristina Yasuda]

This kind of credential always has to be presented with a physical credential

[David W Chadwick]

I support this use case as it will allow one family member to hold the credentials for the entire family

[Torsten Lodderstedt]

There are numerous examples of credentials that are not bound to a cryptographically verifiable identifiers but to a user’s identity. We should document and support this kind of credential.

[Kristina Yasuda]

2022-Mar-19 SIOP call. agreed to do a PR on this

[Tobias Looker]

Just a note that some cryptographic schemes offer things like replay attack protection and some form of holder authentication without having to explicitly bind to cryptographic material supplied by the holder, the BBS signature scheme is one such example (https://identity.foundation/bbs-signature/draft-bbs-signatures.htm), semi related usecase elaboration here (https://identity.foundation/bbs-signature/draft-bbs-signatures.html#name-improved-bearer-security-to)

[Jeremie Miller]

What Tobias just mentioned is a very important distinction.

A presentation that does not have any form of replay protection or binding is (cryptographically) indistinguishable from a credential issuance, the credential is unprotected and can be copied. This is Smart Health Cards.

In the case of BBS, the issued credential itself is a secret and only derivations of it are presented, so in essence it is a form of binding in that the credential’s signature is a shared secret transferred from the issuer to the holder (and the credential is bound to that secret).

So, the question asked here may actually be one of two different more fundamental ones:

Is a credential “verifiable” if it has no mechanism to protect presentations? – OR – Is a presentation “verifiable” if it has no replay prevention?

If we require replay prevention in 4VP, our 4VCI language should also require a method that enables that. And as Tobias points out, there are methods where that is implicit in the issuance (and doesn’t require any specific additional protocol mechanism to support it).

[Tobias Looker]

In the case of BBS, the issued credential itself is a secret and only derivations of it are presented, so in essence it is a form of binding in that the credential’s signature is a shared secret transferred from the issuer to the holder (and the credential is bound to that secret).

+1 this is a good description of “why” this is the case w.r.t BBS.

Is a credential “verifiable” if it has no mechanism to protect presentations? – OR – Is a presentation “verifiable” if it has no replay prevention?

IMO when it comes to credential verifiability it is mainly talking about whether the information is verifiable back to the issuer so I dont think the definition for “verifiable” should extend to whether the credential features a mechanism to protect its presentation against replay attacks.

w.r.t presentations this is where I think the current language around VP’s runs aground, because if I had a set of credentials (like SHCs) that feature no replay attack prevention mechanism, what about a resulting composition presentation of these credentials is verifiable beyond the individual credentials themselves? Im not sure at this stage how we address this in our language but we should be careful to consider these kinds of questions.

‌

‌

[David W Chadwick]

I agree with Tobias that credential verifiability is to do with the ability of the RP to check that the content was issued by the issuer and has not been tampered with since issuance. It is not concerned with replayability. On the contrary, VCs are designed to be presented multiple times. However the issuer should be concerned with PoP in the broadest sense i.e. is the holder allowed to hold this credential, and based on this decision it will issue the VC to the holder or not. I believe this current issue is discussing whether the issuer should issue the credential to someone who cannot prove possession of the subject’s private key. Interestingly we have implemented this feature by using transient keys which are only there to Prove Possession of the credential and not to identify the subject. (The subject is identified by the subject’s attributes/claims). If the issuer is happy that the holder (NE subject) is entitled to hold the credential then the subject id is set to this key ID so that the verifier knows that the holder was entitled to hold it, as the holder can prove possession during presentation. But the key is not related to the identity of the subject as the key is transient. (For those of you that remember SAML this was the original use of IDs in SAML - they were always transient and never persistent).

Presentation non-replayability and binding to the presenter can be performed either in-band or out-of-band. Currently we have in-band fields in the 4VP protocol for both. Out of band PoP could be done for example, by comparing the identity of the credential holder to some external document such as a passport. Out of band single presentation can similarly be done e.g. there is only one seat on the plane for the person with this boarding pass.

[Kristina Yasuda]

I added text to PR #136 that clarifies that the Issuers using certain cryptographic schemes do not require cryptographic material from the Holder to do Holder Binding.

I think we want this specification to support use-cases documented above that issue credentials that only do claim-based subject binding without cryptographic replay protection upon presentation.

[Nat Sakimura]

BTW, I suggest not to use a single word “Holder” as a defined term to represent this actor. Defining a single word will necessarily make its use as a dictionary word impossible. You may say that it is capitalized so they can be differentiated without problems but many languages do not have a “capital / small letter” equivalent. That’s one of the reasons why the ISO Directive prohibits capitalization as the indication of a term and keywords.

‌

[Jeremie Miller]

The VC Data Model 1.0 spec has normative definitions for Holder, Verifier, and Issuer. If we reference that standard as the definition, do you still have concerns?

There’s quite a few dictionary words with specific definitions in Core, so I think there’s lots of precedent: https://openid.net/specs/openid-connect-core-1_0.html#Terminology

Using upper case may not be acceptable in ISO for translation, but it’s a well established pattern in all OpenID and IETF specs. I’m not sure this VCI draft is the right place to start changing this common practice.

[Kristina Yasuda]

Definition of Holder in vc-data-model v1: "A holder is usually, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories." these 2 sentences seem a little contradictory to me - if Holder can store credential (software), but can it also be the subject of credential (physical human as Tobias puts it)

[David W Chadwick]

The original VC eco system model showed the holder as two components, a holder role (usually a human) and a holder agent (software) for interacting with the issuer and verifier. In the latest version this got simplified into a single square. So you are correct, the holder is two entities: usually a human and a wallet.

‌

[Kristina Yasuda]

PR #136 merged

[Kristina Yasuda]

To Nat’s point, I replaced the term Holder entirely in the draft (as of March 2022-Mar-31). Instead it’s binding to the cryptographic binding to the “identifier of the End-User possessing the credential“. with a caveat that “claims in the credential are usually about the End-User who possesses it, but can be about the other entity.”