Presenting VC without a VP using OpenID4VP

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1537

Original Reporter: KristinaYasuda

A use-case being… A doctor is employed by an agency B, who has a contract with hospital A. So to prove that he works for hospital A, the doctor needs to send a VC1 that he works for agency B hospital A and VC2 that the agency B is contracted by hospital A.

Doctor can create a VP1 of VC1, because it is issued to him, but he cannot create a VP of VC2 because VC2 is issued to an agency. but it should be ok as long as verifier trusts hospital’s signature.

I think theoretically, it could be expressed in a descriptor_map in a presentation_submission that one VC can be found inside a VP and another VC is not inside a VP but as-is?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

Several points to note here.

1. A holder can create a VP from any VCs that it holds in its wallet, regardless of whether he is the subject or not. So both of the VCs you refer to can be inside the one VP. The RP can prove possession of VC1 (as the holder is the subject and has signed the VP) but not of VC2, but does that matter? VC2 is simply a statement of fact issued by hospital A. Any holder can assert this statement in a VC inside a VP without being the subject of the VC. It is up to the RP whether to trust this assertion or not.
2. If the RP needs to prove possession of all the VCs that a holder presents, this is easy for ones in which subject=holder, but difficult when subject NE holder. The VC DM describes various alternatives for this. In your example, if the RP trusts hospital A, the latter asserts that it has contracted agency B in VC2. So the RP can obtain the public key of agency B and transitively trust this. Then it has VC1 signed by agency B that says that the doctor is working at hospital A. So the RP can transitively trust this and it obtains the doctors public key. Finally the VP is signed by the doctor, so the RP can prove possession of VC1 by the doctor.

To summarise, I don't see any problem with including both VCs in the VP in your example

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dzagidulin

A holder can create a VP from any VCs that it holds in its wallet, regardless of whether he is the subject or not.

‌

+1, yeah!

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

Discussed at June 23rd SIOP call.

I still do not see why would anyone sign a VC as a VP if there is no without holder binding - will do a PR clarifying that a VC can be sent without a VP as-is if there is no holder binding

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dzagidulin

@Kristina

I still do not see why would anyone sign a VC as a VP if there is no without holder binding

The main benefit is for consistency - VPs are a general purpose envelope for VCs, and are useful for holder (presenter) binding, OR just as an envelope for multiple VCs. So saying “requesters shouldn’t encounter VCs un-wrapped” just makes it easier on the receiver – they don’t have to have if-then statements everywhere (if incoming.type === ‘VerifiablePresentation’) then do this, else if incoming.type === ‘VerifiableCredential’ then do something else.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dzagidulin

Forgot to add - it’s worth highlighting that VPs are for (optionally) authenticating the presenter, who doesn’t have to be the subject of the VC within.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

The other benefit is that the VP stops replay attacks, by the Holder including the nonce presented by the RP into the VP and signing the VP.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

thank you! super helpful!

How does the RP know when it needs to verify holder binding and when it does not have to? Using David’s use-case “The RP can prove possession of VC1, but not of VC2“. How does it know VC2 can be accepted without holder binding - preagreed combination of the issuer and a credential type?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dzagidulin

So I think there’s two questions there - 1) how does the RP know when it wants to verify holder binding, and 2) how does it communicate that fact to the wallet/presenter.

For the first question - it really depends on the use case. (Usually, the RP knows what business rules etc it’s operating in). For example, say the RP is requesting a low-value bearer VC. (Meaning, one without a subject id. So like, a VC equivalent of a movie ticket.) It doesn’t need to verify holder binding (it doesn’t need to know who is presenting the VP wrapping that bearer VC), since it doesn’t care who is presenting it, just that a VC is presented.

In another example - you have a very high-value credential (say, a passport or a Permanent Resident card). But the interaction is in-person (via QR code or NFC or similar mechanism). And the VC contains biometrics (say, the person’s picture). And an officer is verifying that the person standing in front of them presenting the VP is the person on the picture. But again, no DID Auth is needed; the RP does not need to verify holder binding. (because the binding is verified out of band, via biometrics)

But of course in many other cases, the use case and business rules do require holder binding.

So then we move on to question 2 - how does the RP communicate that it needs DID Auth / needs holder binding?

That’s usually done on the protocol level – so for example, in protocols that use VPR (Verifiable Presentation Request) syntax, the RP includes an object of type ‘DIDAuth’, which basically says – “so when you hand me the other credentials that I’m asking for, be sure to wrap those in a VP with presenter binding”. And I imagine that the various DIDComm-derived presentation requests we’re using here in this group, have similar mechanisms?

Does that help?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

Thanks, Dmitri! agreed on the first point! On the second point, OpenID4VP uses Presentation exchange as a query language so guess the concrete mechanism will be dependent on PE. Opened an Issue in a PE spec because it was unclear to me how PE would do it… Verifier indicating if holder binding is needed or not · Issue #367 · decentralized-identity/presentation-exchange (github.com)

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

especially with the credentials that use claim-based binding and not cryptographic binding, it should be possible to return VC that is not in a VP

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: danielfyes

I stumbled upon the same issue when reviewing the VP spec. There should be room for “presentations” without holder binding. One use case would be SD-JWT. There, the presentation is the credential (the SD-JWT) plus any number of disclosures, plus an optional Holder Binding JWT. It should be possible to present without having to do HB.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

from the security analysis:

PROBLEM: If no holder binding is used, right now, there is no way to transport the nonce. I.e., an attacker might inject a presentation. In direct post mode, the Verifier might not even find the session. Just having an unsigned nonce would help here - i.e., state.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

SIOP call. discussed to keep the language in the spec text saying the currently (ID-2) OID4VP operates under the assumption that only VPs with cryptographic holder binding are supported. (PR #489)

meanwhile we continue the conversation how to securely exchange presentations without cryptographic holder binding and update the spec text once and if there is a direction.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

regarding holder binding mechanisms other than cryptographic,@{63696ff6c383ad8421462592} said “i think the ISO approach does makes sense to me. meaning, issuer says that a specific key is associated with biometric authentication (or FIDO token etc.) and when verifier sees a signature produced by that key, the verifier can make sure biometric authn was done. this is similar to the confirmation method approach I suggested in w3c. in the case above, wallet unlocks key (in hardware) with biometric authentication.”

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

Daniel, Kristina and I had a conversation about this topic at Identiverse. We agreed it is important to decide whether we always assume a key binding of the presented credentials (i.e. there is always a signature as proof of possession, which also allows cryptographic binding of nonce and audience of the response) or whether we see the need and would support presentation of credentials without key binding. Daniel took the task to create a write up as basis for further discussions.

[alenhorvat]

The issue is not related to VP and signing, but to data modelling and expressing the relationships. The two VCs are different in nature.

Question is: does the agency has the right/mandate to state that the doctor employed by them is working at the hospital?

To express such relationships we use "verifiable accreditations" (one could call them mandates, ...). Accreditations are statements about what a given entity can attest (what VC it can issue). For us this scenario is a non-problem, since the credentials are designed in a way they reference the accreditation. The accreditation can be either a) published in a registry b) part of the signature (signer attribute JOSE header as per ETSI).

How the model applies to this scenario: Hospital issues a VC to the agency stating: you can attest that people employed by you, work at our hospital. Issuer: hospital, subject == holder == agency

When the agency issues a VC to the doctor, it references (can be a local reference like hash) the VC and puts it in the signer header (signed JOSE header). This way the statement is part of the agency-created signature.

When a Doctor presents a VC, it simply includes only the VC that has been issued to her. Namely, the hospital issued VC will already be in the header.

VP is signed by the doctor VP contains a single VC (VC issued to the doctor by the agency) VC signature (created by the agency) contains the VC issued to them by the hospital.

Note that the accreditation/mandate/other statements required for verification, can be transported in the unsigned JOSE header or in a VP.

Edit: it is simpler than it sounds. I can create a full example, if needed.

[bit-jniestroj]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

Daniel, Kristina and I had a conversation about this topic at Identiverse. We agreed it is important to decide whether we always assume a key binding of the presented credentials (i.e. there is always a signature as proof of possession, which also allows cryptographic binding of nonce and audience of the response) or whether we see the need and would support presentation of credentials without key binding. Daniel took the task to create a write up as basis for further discussions.

@tlodderstedt One year ago you mentioned, that Daniel wanted to prepare a basis for further discussions regarding the topic if also credentials without a key binding are supported. Are there any news on that topic?

[jogu]

We did have a related discussion here relatively recently about this: https://github.com/openid/OpenID4VP/issues/161 and also https://github.com/openid/OpenID4VP/issues/61

My belief is no particular protocol changes are needed for this, but that we do need to finesse some of the language in definitions (e.g. vp_token is constrained to be a "verifiable presentation" which is in turn constrained to be "holder bound credentials"; widening that definition seems sensible.) Does that match your understanding?

[bit-jniestroj]

Yes i agree with that. From a protocol level there should be no changes as vp_token could be literally anything. Its just the wording that currently "prevents" credentials without a key binding.

Great to hear that this is still ongoing. If we can support somewhere just ping me. We will have use cases where we don't have a key binding and it would be awesome if that would also comply to the wording of the specification