Threat analysis for Binding between VC and VP

[Nat Sakimura]

I am recording this as a minor priority proposal as a follow up to the comment raised in PR #21.

https://bitbucket.org/openid/connect/pull-requests/21/added-security-considerations-for-binding#comment-233166900

Related to #1228 which was closed by PR #21.

It may be useful to have a separate security analysis document for VC/VP so that people will have a “Go To” document when considering security issues around it.

‌

‌

[Jeremie Miller]

I definitely support further exploration of the VC/VP binding requirements and impacts. I would even claim that a presentation isn’t “verifiable” if there isn’t a binding present.

I don’t believe saying “just use DIDs” is a sufficient answer either as the way to shift responsibility for supporting binding, they add multiple dimensions of additional complexity and only indirectly address the issues in a protocol flow.

Some deployments will want to require a binding to a single device’s hardware crypto element (and we should work with FIDO/WebAuthn on these), others may require binding to only approved holder software (such as in a trust framework) or secured apps (platform provided attestations).

[Kristina Yasuda]

It was discussed on the 07-13-2021 that SIOP V2 draft should have a general text that requires binding, but leave specificities to the used credential type.

[Torsten Lodderstedt]

Binding between VC and VP is defined by the respective VC/VP format and crypto scheme (e.g. jwt vc vs ldp vc vs ldp vc w/bbs+). I don’t see this in scope for this draft.

Note: PR21 was about binding of VC to OIDC transaction and replay prevention. Different topic.

[Jeremie Miller]

This issue isn’t for tracking changes to any drafts, it’s a placeholder for a potential security analysis doc that explores the role of binding overall.

I expect such a doc would include overviews of how the different formats perform the binding as well as the different types of binding.

This is also related to the many references that Tom has collected in his Proof of Presence wiki page.

[Oliver Terbu]

The Presentation Exchange spec allows you to specify whether holder binding is required: https://identity.foundation/presentation-exchange/#holder-binding . If RPs do require this binding, they could just configure the PE accordingly. Validating and verifying the presentation submission would also enforce holder binding in that case. So, I’m not sure if we need to add normative language about holder binding to the spec if it is already supported by the PE spec. Informative language would be definitely a good idea.

[Kristina Yasuda]

VC/VP binding is a verifier policy decision. spec-text wise, we could add a text in OIDC4VP that if verifier want to set a policy for holder binding, this is a mechanism to do so in PE (https://identity.foundation/presentation-exchange/#holder-and-subject-binding)

and we should add a text to OIDC4VP security consideration section about VC/VP binding rather than having a separate security analysis document.

[Jeremie Miller]

I agree with adding it to OIDC4VP, but it would also have to be added to the claims aggregation / credential issuance spec as the same concerns also exist there between the issuer and holder binding of the VC.

There’s also a few different interpretations of “binding”, these few come to mind quickly:

• Is the response bound to the request (“state”)
• Is the response bound to the subject (“nonce”)
• Is the presentation bound to the subject (embedded in the presentation)

‌

[Torsten Lodderstedt]

The binding between request and response is implemented using nonce. What do you mean with binding of the response to the subject?

presentation subject binding uses the presentation type specific crypto.

[Jeremie Miller]

I’m simply referencing the definitions of “state” and “nonce” from OIDC Core: “state” is only request-response pairing, and “nonce” is embedded in the id_token.

Agree, all presentation-subject/holder binding is internal to the VC/VP mechanism. My position is just that having/discussing such a binding is a good security consideration to highlight.

[Kristina Yasuda]

opened a PR #75. Please review if the proposed language is sufficient.

[Kristina Yasuda]

closed by merging PR #75