Network Working Group M. Svensson Internet-Draft SUNET Intended status: Informational L. Johansson Expires: 7 February 2027 J. Rangsmo Siros Foundation 6 August 2026 Credential Presentation to OIDC Claims Bridge draft-svensson-credential-oidc-bridge-00 Abstract This document defines a mechanism for conveying digital credential claims via OpenID Connect (OIDC). It specifies how an OpenID Provider (OP) that collects credentials from a wallet can expose those claims to Relying Parties as standard OIDC claims, enabling existing OIDC deployments to consume digital credentials without implementing any wallet-facing presentation protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Svensson, et al. Expires 7 February 2027 [Page 1] Internet-Draft Credential to OIDC Bridge August 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. OP (Verifier/Bridge) Requirements . . . . . . . . . . . . . . 4 4.1. The presented_credentials Claim . . . . . . . . . . . . . 4 4.1.1. The presented_credentials Array . . . . . . . . . . . 5 4.1.2. Credential Entry Object . . . . . . . . . . . . . . . 6 4.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Authentication Flow . . . . . . . . . . . . . . . . . . . 7 4.4. Credential Mapping . . . . . . . . . . . . . . . . . . . 7 5. RP (Relying Party) Requirements . . . . . . . . . . . . . . . 8 5.1. Requesting Credential Claims . . . . . . . . . . . . . . 8 5.2. Consuming Credential Claims . . . . . . . . . . . . . . . 10 5.3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 11 6. Limitations and Considerations . . . . . . . . . . . . . . . 11 6.1. Claim Set Size Limits . . . . . . . . . . . . . . . . . . 11 6.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 11 6.3. Scope Mapping . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Scope of This Specification . . . . . . . . . . . . . . . 12 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 7.1. SUNET Verifiable Credentials Platform . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.1. Credential Replay . . . . . . . . . . . . . . . . . . . . 13 8.2. Token Leakage . . . . . . . . . . . . . . . . . . . . . . 14 8.3. Claim Injection . . . . . . . . . . . . . . . . . . . . . 14 8.4. Privacy Considerations . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. JSON Web Token Claims Registration . . . . . . . . . . . 15 9.2. OpenID Connect Discovery Metadata Registration . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Svensson, et al. Expires 7 February 2027 [Page 2] Internet-Draft Credential to OIDC Bridge August 2026 1. Introduction Digital credential wallets can present verified claims to verifiers using protocols such as OpenID for Verifiable Presentations (OpenID4VP) [OpenID4VP] or DIDComm. However, many existing services rely on OpenID Connect (OIDC) [OpenID.Core] for authentication and attribute retrieval, and implementing a wallet-facing presentation protocol represents a significant barrier for these Relying Parties. This document specifies how an OP, acting as a bridge, can collect credentials from a wallet using any suitable presentation protocol and expose the resulting claims in standard OIDC ID Tokens and UserInfo responses. The Relying Party interacts with a normal OIDC flow and receives credential data in the "presented_credentials" claim without needing any knowledge of the underlying presentation protocol. This specification is intended to complement, not compete with, work produced by the OpenID Foundation. Implementers are encouraged to follow developments in the OpenID Foundation's Digital Credentials Protocols working group. 2. Architecture Overview The following diagram illustrates the high-level interaction between the participants: +--------+ +------------------+ +----------+ | | 1. OIDC AuthN | OP | 2. Present | | | RP | -------------> | (Bridge) | ----------> | Wallet | | | | | <---------- | | | | | | 3. Response | | | | | | +----------+ | | | 4. Verify & | | | 5. ID Token | extract claims| | | <------------- | | +--------+ +------------------+ The presentation protocol (step 2-3) is out of scope. The OP may use OpenID4VP, DIDComm, or any other mechanism. Flow: 1. RP sends OIDC AuthN Request to OP (credential scopes). 2. OP requests credential presentation from wallet. 3. Wallet responds with disclosed credentials. Svensson, et al. Expires 7 February 2027 [Page 3] Internet-Draft Credential to OIDC Bridge August 2026 4. OP verifies credentials and extracts claims. 5. OP returns ID Token/UserInfo with presented_credentials. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. OP (Verifier/Bridge) Requirements 4.1. The presented_credentials Claim The following is a non-normative example of an OIDC ID Token containing the "presented_credentials" claim with a credential set containing two credentials: Svensson, et al. Expires 7 February 2027 [Page 4] Internet-Draft Credential to OIDC Bridge August 2026 { "iss": "https://issuer.example.org", "sub": "user@example.org", "iat": 1722772800, "exp": 1722859200, "presented_credentials": [ { "ehic": [ { "format": "vc+sd-jwt", "vct": "https://credentials.example.org/ehic", "claims": { "name": "John Doe", "dob": "1990-01-01", "ehic_number": "1234567890" } } ], "pda1": [ { "format": "vc+sd-jwt", "vct": "https://credentials.example.org/pda1", "claims": { "name": "John Doe", "dob": "1990-01-01", "pda1_number": "0987654321" } } ] } ] } 4.1.1. The presented_credentials Array The "presented_credentials" claim is a top-level JSON array included in the OIDC ID Token or UserInfo response. It contains credential data obtained via a credential presentation flow (e.g., OpenID4VP, DIDComm), re-packaged for consumption by OIDC Relying Parties. The array contains one or more Credential Set objects. Each Credential Set is a JSON object where each key is a scope value corresponding to a credential type and each value is a JSON array of Credential Entry objects as defined in Section 4.1.2. Within a Credential Set: * Each key MUST be unique. Svensson, et al. Expires 7 February 2027 [Page 5] Internet-Draft Credential to OIDC Bridge August 2026 * Each value (array) MUST contain at least one Credential Entry. Multiple entries indicate the wallet presented more than one credential of that type. The outer array MUST contain at least one Credential Set. In most deployments a single set is returned; multiple sets are possible when the RP requested alternatives (see Section 5.1). Additional members within a Credential Set MAY be present. Implementations that do not recognise additional members MUST ignore them. 4.1.2. Credential Entry Object Each Credential Entry object represents a single credential presented during the presentation flow. It MUST contain the following member: claims A JSON object [RFC8259] containing the disclosed claims from the credential. Each key is a claim name and each value is the claim value. Claim names are determined by the credential type and MUST be strings. Claim values MAY be any valid JSON type. A Credential Entry object MAY contain the following additional members: format A string indicating the original credential format (e.g., "vc+sd- jwt", "mso_mdoc"). If omitted, the format is unspecified. vct A string containing the Verifiable Credential Type identifier, as defined in the credential's metadata. Additional members MAY be present. Implementations that do not recognise additional members MUST ignore them. 4.2. Discovery An OP that supports this bridge mechanism MUST include "presented_credentials" in the "claims_supported" list in its OpenID Connect Discovery [OpenID.Discovery] metadata document. The OP SHOULD also advertise the credential types it can collect by listing the corresponding scopes in the "scopes_supported" discovery metadata field (e.g., "ehic", "pda1"). Svensson, et al. Expires 7 February 2027 [Page 6] Internet-Draft Credential to OIDC Bridge August 2026 The OP MAY additionally include a "presented_credentials_supported" member in its discovery metadata. The value is a JSON array of objects, each containing at minimum a "scope" string and a "vct" string, providing RPs with a machine-readable mapping between scopes and credential types. 4.3. Authentication Flow When the OP receives an OIDC Authentication Request that includes a request for credentials (via the "requested_credentials" claims parameter or a registered scope), it MUST: 1. Initiate a credential presentation request to the user's wallet for the requested credential types, using the presentation protocol supported by the deployment. 2. Verify the presented credentials according to the applicable trust framework. 3. Extract the disclosed claims from each verified credential. 4. Construct the "presented_credentials" object as defined in Section 4.1.1. 5. Include the "presented_credentials" claim in the ID Token, the UserInfo response, or both, depending on the OP's policy and the size considerations described in Section 6.1. Common presentation protocols include OpenID4VP [OpenID4VP] and DIDComm Present Proof. The choice of protocol is a deployment decision and does not affect the "presented_credentials" format returned to the RP. 4.4. Credential Mapping The OP MUST use the scope value as the key within the "credentials" object. For example, if the RP requested scope "ehic", the resulting entry MUST be keyed as "ehic". This ensures a predictable, stable mapping between the RP's request and the response. The OP MUST NOT include claims that were not disclosed by the wallet. The OP MUST NOT modify claim values during the mapping. The OP is responsible for translating the RP's OIDC-level request (scopes, claims parameter) into a protocol-specific credential query directed at the wallet. For example, when using OpenID4VP the OP would construct a DCQL (Digital Credentials Query Language) query matching the requested credential types; when using DIDComm the OP Svensson, et al. Expires 7 February 2027 [Page 7] Internet-Draft Credential to OIDC Bridge August 2026 would build a Present Proof request. This translation is deployment- specific and outside the scope of this specification. The OP MUST document the mapping between OIDC scopes and the credential types they resolve to, either in its discovery metadata or in out-of-band documentation. The OIDC request model (scopes and the "claims" parameter) is intentionally simpler than the query languages available in presentation protocols (e.g., DCQL in OpenID4VP). This means that certain constraints expressible in a presentation query — such as issuer restrictions, issuance date filters, or compound field requirements — cannot be communicated by the RP. The OP MUST apply its own policy to resolve these edge cases (for example, by selecting the most recent matching credential or by restricting accepted issuers via configuration). The OP SHOULD document any such policies so that RPs can anticipate the resulting behaviour. The structure of the "presented_credentials" claim MUST be independent of the credential presentation protocol used between the OP and the wallet. Whether the OP collected credentials via OpenID4VP, DIDComm, or any other mechanism, the resulting claim format MUST conform to this specification. The RP MUST NOT need to be aware of which presentation protocol was used. 5. RP (Relying Party) Requirements 5.1. Requesting Credential Claims An RP that wishes to receive credential data via this bridge MUST include the appropriate credential type scopes in the OIDC Authentication Request. Each scope corresponds to a credential type (e.g., "ehic", "pda1"). The presence of any credential type scope signals to the OP that the "requested_credentials" claim parameter applies. The requested scopes directly correlate to the keys in credential sets returned by the OP. For example, if the RP requests scopes "ehic" and "pda1", the OP will return a credential set containing "ehic" and "pda1" entries. The RP MAY additionally use the "claims" request parameter to specify which individual claims within a credential type are desired, enabling selective disclosure. The RP MAY use the "credential_sets" structure within the "requested_credentials" claims request parameter to express combinatorial logic over credential types: Svensson, et al. Expires 7 February 2027 [Page 8] Internet-Draft Credential to OIDC Bridge August 2026 * _AND (within a set):_ Credentials listed in the same credential set with "essential": true are all required. The OP MUST fail the authentication if any essential credential in the set cannot be obtained. * _OR (between sets):_ Multiple credential sets represent alternatives. The OP MUST attempt to satisfy the sets in order and use the first set that can be fully satisfied. Only one credential set is returned in the response. The following is a non-normative example requesting PID AND EHIC together (both are required): { "id_token": { "requested_credentials": { "credential_sets": [ { "pid": { "essential": true, "claims": ["name"] }, "ehic": { "essential": true, "claims": ["ehic_number"] } } ] } } } The following is a non-normative example requesting PID OR EHIC (either one satisfies the RP). The OP tries the first set; if the wallet cannot provide a PID, it falls back to the second set: { "id_token": { "requested_credentials": { "credential_sets": [ { "pid": { "essential": true, "claims": ["name"] } }, { "ehic": { "essential": true, "claims": ["ehic_number"] } } ] } } } The following is a non-normative example requesting PID (required) with EHIC as optional (nice-to-have): Svensson, et al. Expires 7 February 2027 [Page 9] Internet-Draft Credential to OIDC Bridge August 2026 { "id_token": { "requested_credentials": { "credential_sets": [ { "pid": { "essential": true, "claims": ["name"] }, "ehic": { "essential": false, "claims": ["ehic_number"] } } ] } } } If any credential marked essential is missing from the wallet's response and no alternative set can be satisfied, the OP MUST return an OIDC error response (e.g., "access_denied") rather than a partial credential set. If the wallet presents multiple credentials of the same type (e.g., two EHICs for different family members), the OP returns all of them in the array. The RP is responsible for selecting the appropriate credential by inspecting the returned claims (for example, matching on name or date of birth against the authenticated user's identity). 5.2. Consuming Credential Claims The "presented_credentials" claim structure is defined in Section 4.1. The RP MUST parse the claim according to that definition. Specifically, the RP MUST: 1. Check for the presence of the "presented_credentials" claim. If the claim was requested as essential and is absent, the RP SHOULD treat the authentication as failed. 2. Parse the "credentials" object and extract the entries relevant to its use case. 3. Validate that the expected claims are present in each Credential Entry's "claims" object. The RP MUST NOT assume that all requested scopes will be present in the response; the user may have declined to present certain credentials. The RP MUST ignore unrecognised credential keys and unrecognised members within Credential Entry objects. Svensson, et al. Expires 7 February 2027 [Page 10] Internet-Draft Credential to OIDC Bridge August 2026 5.3. Trust Model The RP places trust in the OP to have correctly verified the presented credentials. The RP does not interact with the wallet or credential issuer directly. The trust relationship between the RP and the OP is established through standard OIDC mechanisms (client registration, token validation, TLS). 6. Limitations and Considerations 6.1. Claim Set Size Limits OIDC ID Tokens are typically passed as JWTs [RFC7519] in HTTP headers or URL fragments, which impose practical size limits. Browser URL length limits are commonly around 2048 bytes, and many HTTP servers reject headers exceeding 8192 bytes. When multiple credentials with many disclosed claims are included in the "presented_credentials" object, the resulting token may exceed these limits. Implementations SHOULD consider the following mitigations: * Return credential claims via the UserInfo endpoint rather than embedding them directly in the ID Token. * Limit the number of disclosed claims to those requested by the Relying Party via the OIDC "claims" parameter. * Use token introspection or reference tokens where supported by the deployment. 6.2. Error Handling The OP MUST handle the following failure scenarios gracefully: Wallet rejection The user declines to present credentials. The OP MAY either omit the "presented_credentials" claim entirely or return an OIDC error response (e.g., "access_denied") depending on whether the credential presentation was essential to the authentication. Wallet timeout The wallet does not respond within a reasonable time. The OP SHOULD treat this as equivalent to a rejection. Invalid credentials The wallet presents credentials that fail verification (expired, revoked, untrusted issuer). The OP MUST NOT include unverified credential claims in the "presented_credentials" object. The OP MAY proceed without those credentials or fail the authentication. Svensson, et al. Expires 7 February 2027 [Page 11] Internet-Draft Credential to OIDC Bridge August 2026 Partial presentation The wallet presents only a subset of the requested credentials. The OP MUST include only the successfully verified credentials and MUST NOT fabricate entries for missing credentials. 6.3. Scope Mapping An OP MAY define custom OIDC scopes that map to specific credential presentation requests. For example, the scope "ehic" might trigger a request for an EHIC credential with a predefined set of claims. When using scope-based mapping, the OP SHOULD document the mapping between scopes and credential types in its discovery metadata or out- of-band documentation. The OP MUST ensure that the scope semantics are stable and do not change unexpectedly for registered RPs. 6.4. Scope of This Specification This specification defines the data format of the "presented_credentials" claim, the mechanism for requesting and returning credential claims via OIDC, and the responsibilities of the OP and RP in that exchange. The following aspects are explicitly out of scope: * _Credential validation policy._ This specification does not define which issuers to trust, which revocation mechanisms to check, or what trust frameworks to apply. These decisions are deployment- specific and determined by the OP operator. * _Business logic and authorization decisions._ How the RP interprets the received claims — for example, whether an EHIC credential grants access to a healthcare service, or whether a PDA1 is sufficient for a given transaction — is entirely the RP's responsibility and outside this specification. * _Credential issuance._ This specification deals only with presentation of existing credentials, not with the issuance of new credentials (which is covered by OpenID4VCI). * _Wallet implementation._ The interaction between the OP and the wallet uses a presentation protocol such as OpenID4VP or DIDComm. This specification does not mandate a specific protocol and does not impose additional requirements on wallet implementations. * _User consent and identity matching._ How the OP associates a credential presentation with an OIDC subject identifier, and how user consent is obtained, are implementation details left to the OP. Svensson, et al. Expires 7 February 2027 [Page 12] Internet-Draft Credential to OIDC Bridge August 2026 In summary, this specification provides the plumbing for transporting verified credential claims through OIDC. Everything above that layer — trust decisions, access control, and business rules — is the domain of the deploying parties. 7. Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. 7.1. SUNET Verifiable Credentials Platform Organization SUNET (Swedish University Computer Network) Implementation Open-source verifiable credentials platform including issuer, verifier, and wallet components with an API gateway implementing the OpenID4VP-to-OIDC bridge described in this document. Description The implementation supports SD-JWT VC [SD-JWT.VC] and mdoc [ISO.18013-5] credential formats, exposes the "presented_credentials" claim via both ID Token and UserInfo endpoint, and has been deployed in production for European higher- education credential use cases (EHIC, PDA1, micro-credentials). Maturity Production Coverage Implements all normative requirements of this specification. Contact masv@sunet.se Source Code https://github.com/SUNET/vc (open source, BSD-2-Clause) 8. Security Considerations 8.1. Credential Replay The OP MUST ensure that credential presentations are bound to the current authentication session. The OP SHOULD use nonces in the OpenID4VP request to prevent replay of previously captured VP Tokens. Svensson, et al. Expires 7 February 2027 [Page 13] Internet-Draft Credential to OIDC Bridge August 2026 The RP MUST validate standard JWT claims ("iat", "exp", "nonce") in the ID Token to ensure freshness of the "presented_credentials" claim. 8.2. Token Leakage ID Tokens containing "presented_credentials" may carry sensitive personal data (e.g., national ID numbers, health information). Implementations MUST use TLS for all token transmissions. The OP SHOULD prefer delivering credential claims via the UserInfo endpoint (which uses a back-channel request) rather than embedding them in the ID Token (which may be exposed in browser history or logs). 8.3. Claim Injection The OP MUST NOT allow external parties to inject or modify claims within the "presented_credentials" object. The OP MUST populate this claim exclusively from verified credential presentations. The ID Token MUST be signed by the OP to protect integrity. 8.4. Privacy Considerations The bridge architecture introduces the OP as a party that observes all credential claims presented by the user. This creates a correlation point. Deployments SHOULD consider the following: * The OP SHOULD request only the minimum claims necessary to satisfy the RP's request (selective disclosure). * The OP SHOULD NOT log or persist credential claims beyond what is necessary for the authentication session. * RPs SHOULD be aware that repeated presentations of the same credential claims across sessions may enable correlation by the OP. * Where possible, deployments SHOULD use pairwise subject identifiers to limit cross-RP correlation. 9. IANA Considerations The claim name "presented_credentials" was chosen to be protocol- agnostic, clearly describing the content (credentials that were presented) without implying a dependency on any particular presentation protocol or namespace. Svensson, et al. Expires 7 February 2027 [Page 14] Internet-Draft Credential to OIDC Bridge August 2026 9.1. JSON Web Token Claims Registration This specification requests registration of the following claim in the IANA "JSON Web Token Claims" registry: Claim Name presented_credentials Claim Description Digital credential claims obtained via an OpenID4VP presentation, structured for consumption by OIDC Relying Parties. Change Controller IETF Specification Document(s) Section 4.1.1 of this document 9.2. OpenID Connect Discovery Metadata Registration This specification requests registration of the following metadata parameter: Metadata Name presented_credentials_supported Metadata Description A JSON array describing the credential types the OP can collect via OpenID4VP and expose as OIDC claims. Change Controller IETF Specification Document(s) Section 4.2 of this document 10. References 10.1. Normative References [OpenID4VP] Terbu, O., Lodderstedt, T., Yasuda, K., and T. Looker, "OpenID for Verifiable Presentations (OpenID4VP) 1.0", 2024, . [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., Medeiros, B. de., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, . Svensson, et al. Expires 7 February 2027 [Page 15] Internet-Draft Credential to OIDC Bridge August 2026 [OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0", November 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 10.2. Informative References [ISO.18013-5] ISO/IEC, "Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application", 2021, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [SD-JWT.VC] Terbu, O. and D. Fett, "SD-JWT-based Verifiable Credentials (SD-JWT VC)", 2024, . Acknowledgments TODO acknowledge. Svensson, et al. Expires 7 February 2027 [Page 16] Internet-Draft Credential to OIDC Bridge August 2026 Authors' Addresses Magnus Svensson SUNET Email: masv@sunet.se Leif Johansson Siros Foundation Email: leifj@siros.org Joel Rangsmo Siros Foundation Email: joel@siros.org Svensson, et al. Expires 7 February 2027 [Page 17]