Added support for credentials without cryptographic holder binding #210

tlodderstedt · 2025-07-16T17:48:56Z

resolves #105

openid4vc-high-assurance-interoperability-profile-1_0.md

jogu · 2025-07-22T15:30:33Z

openid4vc-high-assurance-interoperability-profile-1_0.md

 ### Cryptographic Holder Binding between VC and VP

-* For Cryptographic Holder Binding, a KB-JWT, as defined in [@!I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.
+* If the credential has cryptographic holder binding, a KB-JWT, as defined in [@!I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.


Suggested change

* If the credential has cryptographic holder binding, a KB-JWT, as defined in [@!I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.

* If the credential has cryptographic key binding, a KB-JWT, as defined in [@!I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.

this needs to be cryptographic key binding

HAIP uses VCI terminology, which is "holder binding" - applied this terminology consistently for this PR

to be be compliant to the rest of the text and assuming this VCI PR gets merged, holder binding is correct (to my personal disagreement)

openid4vc-high-assurance-interoperability-profile-1_0.md

awoie

If @jogu 's suggestions were applied, then LGTM

Co-authored-by: Joseph Heenan <joseph@authlete.com>

jogu · 2025-08-05T14:40:45Z

If @jogu 's suggestions were applied, then LGTM

Torsten & I discussed this - VCI & VP are unfortunately inconsistent in the terms they use, and 'Crytographic holder binding' is currently the most used term in HAIP, so I withdrew my suggestions.

openid4vc-high-assurance-interoperability-profile-1_0.md

Sakurann · 2025-08-07T15:51:10Z

openid4vc-high-assurance-interoperability-profile-1_0.md

 ### Key Attestation {#key-attestation}

-Wallets MUST support key attestations as defined in Annex D of [@!OIDF.OID4VCI]. If batch issuance is used, all public keys used in Credential Request SHOULD be attested within a single key attestation.
+Wallets MUST support key attestations as defined in Annex D of [@!OIDF.OID4VCI]. If batch issuance is used and the Credential Issuer has indicated (via `cryptographic_binding_methods_supported ` in it's metadata) that cryptographic binding is required, all public keys used in Credential Request SHOULD be attested within a single key attestation.


Suggested change

Wallets MUST support key attestations as defined in Annex D of [@!OIDF.OID4VCI]. If batch issuance is used and the Credential Issuer has indicated (via `cryptographic_binding_methods_supported ` in it's metadata) that cryptographic binding is required, all public keys used in Credential Request SHOULD be attested within a single key attestation.

Wallets MUST support key attestations as defined in Annex D of [@!OIDF.OID4VCI]. If batch issuance is used and the Credential Issuer has indicated (via `cryptographic_binding_methods_supported ` metadata parameter) that cryptographic key binding is required, all public keys used in Credential Request SHOULD be attested within a single key attestation.

partially adopted the proposal (holder instead of key)

openid4vc-high-assurance-interoperability-profile-1_0.md

Sakurann · 2025-08-07T15:53:32Z

openid4vc-high-assurance-interoperability-profile-1_0.md

 ### Cryptographic Holder Binding between VC and VP

-* For Cryptographic Holder Binding, a KB-JWT, as defined in [@!I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.
+* If the credential has cryptographic holder binding, a KB-JWT, as defined in [@!I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.


this needs to be cryptographic key binding

Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

paulbastian

Under the condition that HAIP#165 and VCI#621 gets merged, this looks good to me.

paulbastian · 2025-08-26T12:26:11Z

openid4vc-high-assurance-interoperability-profile-1_0.md

 | iat | MUST |[@!RFC7519], Section 4.1.6 |
 | exp | SHOULD (at the discretion of the Issuer) | [@!RFC7519], Section 4.1.4 |
-| cnf |	MUST |	[@!RFC7800]|
+| cnf | MUST if the corresponding Credential Configuration requires cryptographic holder binding | [@!RFC7800]|


I believe we remove the table with #165 , so this change becomes obsolete

paulbastian · 2025-08-26T12:36:06Z

openid4vc-high-assurance-interoperability-profile-1_0.md

 ### Cryptographic Holder Binding between VC and VP

-* For Cryptographic Holder Binding, a KB-JWT, as defined in [@!I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.
+* If the credential has cryptographic holder binding, a KB-JWT, as defined in [@!I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.


to be be compliant to the rest of the text and assuming this VCI PR gets merged, holder binding is correct (to my personal disagreement)

first draft

83aee15

tlodderstedt changed the title ~~Added support for credentials without cryptographic key binding~~ Added support for credentials without cryptographic holder binding Jul 16, 2025

jogu reviewed Jul 22, 2025

View reviewed changes

This was referenced Jul 24, 2025

remove any mandatory requirements for key attestations #188

Closed

Clarify support for claims-based bound credentials #105

Closed

awoie reviewed Jul 29, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

awoie reviewed Jul 29, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Show resolved Hide resolved

awoie reviewed Jul 29, 2025

View reviewed changes

tlodderstedt and others added 3 commits August 1, 2025 18:12

Update openid4vc-high-assurance-interoperability-profile-1_0.md

daccc9e

Co-authored-by: Joseph Heenan <joseph@authlete.com>

Update openid4vc-high-assurance-interoperability-profile-1_0.md

bc1e2ad

Co-authored-by: Joseph Heenan <joseph@authlete.com>

Update openid4vc-high-assurance-interoperability-profile-1_0.md

e38f17e

Co-authored-by: Joseph Heenan <joseph@authlete.com>

jogu approved these changes Aug 3, 2025

View reviewed changes

jogu added the needs-reviews label Aug 4, 2025

Sakurann reviewed Aug 7, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

Sakurann reviewed Aug 7, 2025

View reviewed changes

Sakurann requested changes Aug 7, 2025

View reviewed changes

Sakurann and others added 4 commits August 7, 2025 17:54

Merge branch 'main' into add-support-non-key-bound-credentials

74e1e40

Update openid4vc-high-assurance-interoperability-profile-1_0.md

5c061f6

Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

Update openid4vc-high-assurance-interoperability-profile-1_0.md

c0fea49

Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

adopted some of the proposed changes

00afcfd

Sakurann added this to the 1.0 Final milestone Aug 12, 2025

jogu added needs-reviews and removed needs-reviews labels Aug 14, 2025

jogu requested review from Sakurann and paulbastian August 14, 2025 16:38

Merge branch 'main' into add-support-non-key-bound-credentials

4d86a63

Sakurann requested a review from awoie August 19, 2025 18:26

Sakurann approved these changes Aug 19, 2025

View reviewed changes

Sakurann mentioned this pull request Aug 19, 2025

Not all credentials are high assurance, should HAIP support those other cases? #184

Closed

paulbastian approved these changes Aug 26, 2025

View reviewed changes

Sakurann merged commit e8b6c97 into main Aug 26, 2025
2 checks passed

	* If the credential has cryptographic holder binding, a KB-JWT, as defined in [@!I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.
	* If the credential has cryptographic key binding, a KB-JWT, as defined in [@!I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.

	Wallets MUST support key attestations as defined in Annex D of [@!OIDF.OID4VCI]. If batch issuance is used and the Credential Issuer has indicated (via `cryptographic_binding_methods_supported ` in it's metadata) that cryptographic binding is required, all public keys used in Credential Request SHOULD be attested within a single key attestation.
	Wallets MUST support key attestations as defined in Annex D of [@!OIDF.OID4VCI]. If batch issuance is used and the Credential Issuer has indicated (via `cryptographic_binding_methods_supported ` metadata parameter) that cryptographic key binding is required, all public keys used in Credential Request SHOULD be attested within a single key attestation.

Added support for credentials without cryptographic holder binding #210

Added support for credentials without cryptographic holder binding #210

Uh oh!

Conversation

tlodderstedt commented Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

awoie left a comment

Choose a reason for hiding this comment

Uh oh!

jogu commented Aug 5, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paulbastian left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

tlodderstedt commented Jul 16, 2025 •

edited

Loading