OpenID4VP

OpenID4VP copied to clipboard

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?

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

‌

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!

‌

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

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.

‌

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.

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.

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?

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?

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)

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

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.

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.

‌

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.

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.”

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.

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.

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?

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?

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

@Sakurann @tlodderstedt @jogu If this is scheduled for 1.1, it looks like a breaking change to me. Currently section 14.1 reads very strong, allowing only Credentials with cryptographic binding. I think there are legitimate use cases not having such a binding, e.g. using claim-based binding

This is also in contradiction to OpenID4VCI?

The OID4VP spec currently requires key binding. "This specification assumes that a Verifiable Credential is always presented with a cryptographic proof of possession which can be a Verifiable Presentation. This cryptographic proof of possession MUST be bound by the Wallet to the intended audience (the Client Identifier of the Verifier) and the respective transaction (identified by the nonce parameter in the Authorization Request). The Verifier MUST verify this binding."

Key question: Do we keep the spec as is, which means the protocol only supports presentation of digital credentials with key binding or does the protocol also support the presentation of digital credentials without key binding (and for example claims based binding instead)?

Different opinions in the call, for example: Daniel: introducing keys for any credential (but accept low security levels) might render the mechanisms less trustworthy Lee: sending just credentials without key binding to a RP is not a presentation (which includes session binding and so on)

Daniel to make a proposal how the text could be modified to cater for digital credentials without key binding as basis for further discussions.

I think there is value in adding this feature, but we should try to be very precise in terms of security implications in the spec and this "mode" should also be clearly signalled in the protocol to avoid mistakes by lazy Verifier implementations.

There are a couple of ways we could implement this feature:

DCQL Request

Encoding that a credential doesn't need a presentation in the response should be fairly easy to add to DCQL:

{
  "credentials": [
    {
      "id": "my_credential",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [ "https://credentials.example.com/identity_credential" ]
      },
      "no_binding_needed": true,
      "claims": [
          {"path": ["last_name"]},
          {"path": ["first_name"]},
          {"path": ["address", "street_address"]}
      ]
    }
  ]
}

Response

Solution A - Enforce that at least one credential with key binding is presented in each response. Any number of credentials without key binding can be presented at the same time (as requested in the DCQL query).

{
  "cred_with_kb": "eyJhbGci...QMA~eyJh...kEA",
  "other_cred": "eyJhbGci...QMA"
}

This way, the nonce would always be available for checking. We would keep practically all security guarantees for the response. Of course, the non-key-bound credential could be replayed, but that is inherent to any presentation without key binding.

The protocol would not be able to support cases where only non-key-bound credentials are presented.

Solution B1 - If no key-bound credential is presented, send the nonce, audience and whatever else we think is important in the VP Token in the response as separate, unsigned items. A problem would be to ensure that there are no clashes between the nonce/aud and a credential. Squigglies to the rescue, as they're not allowed in IDs in DCQL.

{
  "cred_with_kb": "eyJhbGci...QMA~eyJh...kEA",
  "~unsigned": {"nonce": "4hqnKvw5l9", "aud": "client.example"}
}

Another problem is that the nonce and audience are now not cryptographically protected. That might be okay, however, as injection of responses is still hard.

A small risk is that Wallets always send the nonce and audience like this, even if they're not needed, and verifiers start relying on them for comparing what's in the presentation for key-bound credentials (i.e., comparing the signed nonce with the plaintext nonce from the response without checking it against the session). The countermeasure would be to define that verifiers MUST NOT accept responses containing these values AND a signed presentation.

Solution B2 - As above, but send nonce and audience in the response as separate parameters outside of the VP Token.

vp_token={...}&aud=...&nonce=...&state=...

What about setting the alg=none in kb-jwt?

What about setting the alg=none in kb-jwt?

Not allowed in SD-JWT (for good reasons, it only led to problems in the past).

What about setting the alg=none in kb-jwt?

I have a bad feeling to use alg none because using a object that seems to be signed and is not is being perceived as a bad idea in general. Additionally, that would only work for sd-jwt and jwt, but not for mdoc (and other credential formats).

But why would the protocol need to know anything about whether the credential is bound or not? Does the security of the protocol rely on whether or not presentation is signed?

If yes, then always require that the presentation (kb-jwt in this case) is signed.

Whether or not to check the key binding, depends on whether cnf is present or not (or equivalent claim in other formats)

1. if there is a "cnf"-> always send KB, if there is none-> don't send it
2. make it very uncomplicated, just don't use the nonce and send the SD-JWT VC as is without KB

WG discussion:

• what Paul put in the comment above ^
• do not do anything in DCQL request and response, and only remove the requirement that credentials in openid4vp have to be key bound and add security considerations that are being lost when credential is not key bound.
  • can also add a section "do not use this in HAIP"? some disagreements.
• there are some credential formats that are hard to tell if they are session bound. might need something that makes it harder to screw it up.
• suggestion: mandate encryption for non-key bound credentials? might be not necessary?
• nonce is always in mdoc sessionTranscript.
• Daniel is sure something needs to be added in the response: nonce in the option or mandate state. only injection and CSRF is prevented