credential issuers establishing trust with wallet providers - #58
Open
peppelinux wants to merge 1 commit into
Open
credential issuers establishing trust with wallet providers#58peppelinux wants to merge 1 commit into
peppelinux wants to merge 1 commit into
Conversation
Terminology — Wallet Attestation and Key Attestation now cite OpenID4VCI (not OpenID4VP). Credential Issuers Establishing Trust in the Wallet Provider — Clarified trust_chain validation for attestations; tied signer to openid_wallet_provider. Credential Issuers Establishing Trust in the Wallet — Rewrote into: Wallet Attestation → OpenID4VCI Appendix E + Attestation-Based Client Auth (PAR/Token, PoP, federation key validation, trust_chain SHOULD) Key Attestation → OpenID4VCI Appendix D/F, §8.2, §12.2.4 (proof_types_supported / key_attestations_required) Framing via OpenID4VCI §13.3 Offline Flows — Wallet and Key Attestations called out as carriers of Federation trust_chain. References — Added I-D.ietf-oauth-attestation-based-client-auth. Document History (-05) — Noted the #29 resolution.
selfissued
reviewed
Aug 15, 2026
| During the issuance phase, the Wallet Instance authenticates with the Credential Issuer using a Client authentication mechanism that includes a proof issued by its Wallet Provider. | ||
| During Credential issuance, establishing trust in the Wallet comprises two related but distinct evaluations, as described in Section 13.3 of [@!OpenID4VCI] (*Trust between Wallet and Issuer*): | ||
|
|
||
| 1. Trust in the Wallet Solution / Wallet Instance authenticity, using Wallet Attestation as client authentication; and |
Member
There was a problem hiding this comment.
Suggested change
| 1. Trust in the Wallet Solution / Wallet Instance authenticity, using Wallet Attestation as client authentication; and | |
| 1. Trust in the Wallet Solution / Wallet Instance authenticity, using the Wallet Attestation as client authentication; and |
selfissued
reviewed
Aug 15, 2026
| During Credential issuance, establishing trust in the Wallet comprises two related but distinct evaluations, as described in Section 13.3 of [@!OpenID4VCI] (*Trust between Wallet and Issuer*): | ||
|
|
||
| 1. Trust in the Wallet Solution / Wallet Instance authenticity, using Wallet Attestation as client authentication; and | ||
| 2. When required, trust in the cryptographic key material and its protection properties, using Key Attestation in the Credential Request. |
Member
There was a problem hiding this comment.
Suggested change
| 2. When required, trust in the cryptographic key material and its protection properties, using Key Attestation in the Credential Request. | |
| 2. When required, trust in the cryptographic key material and its protection properties, using the Key Attestation in the Credential Request. |
selfissued
reviewed
Aug 15, 2026
|
|
||
| ### Wallet Attestation | ||
|
|
||
| During the issuance phase, the Wallet Instance authenticates with the Credential Issuer's Authorization Server using Wallet Attestation as defined in Appendix E of [@!OpenID4VCI], following OAuth 2.0 Attestation-Based Client Authentication [@!I-D.ietf-oauth-attestation-based-client-auth]. The Wallet Attestation is a Client Attestation JWT issued by the Wallet Provider. The Wallet Instance MUST also present a Client Attestation Proof of Possession (PoP) JWT proving control of the key confirmed in the `cnf` claim of that attestation, as specified in [@!I-D.ietf-oauth-attestation-based-client-auth]. |
Member
There was a problem hiding this comment.
Suggested change
| During the issuance phase, the Wallet Instance authenticates with the Credential Issuer's Authorization Server using Wallet Attestation as defined in Appendix E of [@!OpenID4VCI], following OAuth 2.0 Attestation-Based Client Authentication [@!I-D.ietf-oauth-attestation-based-client-auth]. The Wallet Attestation is a Client Attestation JWT issued by the Wallet Provider. The Wallet Instance MUST also present a Client Attestation Proof of Possession (PoP) JWT proving control of the key confirmed in the `cnf` claim of that attestation, as specified in [@!I-D.ietf-oauth-attestation-based-client-auth]. | |
| During the issuance phase, the Wallet Instance authenticates with the Credential Issuer's Authorization Server using Wallet Attestation as defined in Appendix E of [@!OpenID4VCI], following OAuth 2.0 Attestation-Based Client Authentication [@!I-D.ietf-oauth-attestation-based-client-auth]. The Wallet Attestation is a Client Attestation JWT issued by the Wallet Provider. The Wallet Instance MUST also present a Client Attestation Proof of Possession (PoP) JWT proving control of the confirmation key in the `cnf` claim of that attestation, as specified in [@!I-D.ietf-oauth-attestation-based-client-auth]. |
selfissued
approved these changes
Aug 15, 2026
selfissued
left a comment
selfissued
left a comment
Member
There was a problem hiding this comment.
Looks great! Please apply my minor editorial suggestions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
this PR aims to resolve #29
@TimoGlastra ^