Credential Presentation to OIDC Claims Bridge
draft-svensson-credential-oidc-bridge-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Magnus Svensson , Leif Johansson , Joel Rangsmo | ||
| Last updated | 2026-08-24 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-svensson-credential-oidc-bridge-02
TBD M. Svensson
Internet-Draft SUNET
Intended status: Informational L. Johansson
Expires: 25 February 2027 J. Rangsmo
Siros Foundation
24 August 2026
Credential Presentation to OIDC Claims Bridge
draft-svensson-credential-oidc-bridge-02
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.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/masv3971/rfc_credential_oidc_bridge.
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 25 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Svensson, et al. Expires 25 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. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
4. Relying Party Requirements . . . . . . . . . . . . . . . . . 5
4.1. Requesting Credential Claims . . . . . . . . . . . . . . 5
4.1.1. Scope-Based Requests . . . . . . . . . . . . . . . . 5
4.1.2. DCQL-Based Requests . . . . . . . . . . . . . . . . . 6
4.2. Consuming Credential Claims . . . . . . . . . . . . . . . 13
4.3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Liability and Accountability . . . . . . . . . . . . . . 14
5. OpenID Provider Requirements . . . . . . . . . . . . . . . . 15
5.1. The presented_credentials Claim . . . . . . . . . . . . . 15
5.1.1. The presented_credentials Array . . . . . . . . . . . 16
5.1.2. Credential Entry Object . . . . . . . . . . . . . . . 17
5.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3. Authentication Flow . . . . . . . . . . . . . . . . . . . 22
5.4. Credential Mapping . . . . . . . . . . . . . . . . . . . 23
6. Limitations and Considerations . . . . . . . . . . . . . . . 25
6.1. Claim Set Size Limits . . . . . . . . . . . . . . . . . . 26
6.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 26
6.3. Scope Mapping . . . . . . . . . . . . . . . . . . . . . . 27
6.4. Fresh Presentation Requirement . . . . . . . . . . . . . 27
6.5. Scope of This Specification . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Credential Replay . . . . . . . . . . . . . . . . . . . . 28
7.2. Token Leakage . . . . . . . . . . . . . . . . . . . . . . 28
7.3. Claim Injection . . . . . . . . . . . . . . . . . . . . . 28
7.4. Trust Authority Dereferencing . . . . . . . . . . . . . . 29
7.5. Privacy Considerations . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. JSON Web Token Claims Registration . . . . . . . . . . . 30
8.2. OpenID Connect Discovery Metadata Registration . . . . . 30
8.3. Credential Trust Status Values Registry . . . . . . . . . 31
8.4. Credential Holder Binding Methods Registry . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . 34
Svensson, et al. Expires 25 February 2027 [Page 2]
Internet-Draft Credential to OIDC Bridge August 2026
Appendix A. DCQL Binding . . . . . . . . . . . . . . . . . . . . 35
A.1. Scope-Based Mode . . . . . . . . . . . . . . . . . . . . 35
A.2. DCQL-Based Mode . . . . . . . . . . . . . . . . . . . . . 36
A.3. Response Mapping . . . . . . . . . . . . . . . . . . . . 37
A.4. Value Constraint Propagation . . . . . . . . . . . . . . 37
Appendix B. DIDComm Binding . . . . . . . . . . . . . . . . . . 37
Appendix C. Claim Value Matching . . . . . . . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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 | | 2. Present | |
| RP | -------------> | OP (Bridge) | -----------> | Wallet |
| | | | <----------- | |
| | | | 3. Response | |
| | | | +----------+
| | | 4. Verify & |
| | 5. ID Token | extract claims|
| | <------------- | |
+--------+ +------------------+
Svensson, et al. Expires 25 February 2027 [Page 3]
Internet-Draft Credential to OIDC Bridge August 2026
The presentation protocol (steps 2-3) is out of scope for this
specification. The OP MAY use OpenID4VP, DIDComm, or any other
suitable mechanism.
The steps are:
1. The RP sends an OIDC Authentication Request to the OP, including
credential type scopes.
2. The OP initiates a credential presentation request to the user's
wallet.
3. The wallet responds with the disclosed credentials.
4. The OP verifies the credentials and extracts claims.
5. The OP returns an ID Token and/or UserInfo response containing
the "presented_credentials" claim.
3. Conventions and Definitions
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.
The following terms are used throughout this document:
Relying Party (RP) An OIDC client that consumes claims from the OP.
In this specification, the RP receives credential claims without
directly interacting with the wallet.
OpenID Provider (OP) The authorization server that acts as a bridge
between the wallet and the RP. The OP collects credentials from
the wallet using a presentation protocol and exposes the resulting
claims via standard OIDC mechanisms.
Wallet A user-controlled application that holds digital credentials
and can present them to a verifier upon request.
Credential Set A JSON object within the "presented_credentials"
array where each key is a credential type scope and each value is
an array of Credential Entry objects.
Credential Entry A JSON object representing a single credential
presented during the presentation flow, containing metadata and
disclosed claims.
Svensson, et al. Expires 25 February 2027 [Page 4]
Internet-Draft Credential to OIDC Bridge August 2026
4. Relying Party Requirements
4.1. Requesting Credential Claims
An RP that wishes to receive credential data via this bridge MUST
include credential type scopes in the OIDC Authentication Request
(e.g., scope=openid ehic pda1). This specification defines two
request modes:
* _Scope-based (REQUIRED to support):_ the RP includes only
credential type scopes. The OP applies a pre-registered query per
scope (see Section 5.4) and returns the claims configured for that
credential type. Every OP that implements this specification MUST
support this mode.
* _DCQL-based (OPTIONAL):_ the RP additionally supplies a
"dcql_query" member inside the OIDC "claims" request parameter.
The value is a DCQL query [OpenID4VP] constrained to the profile
defined in Section 4.1.2.
Deployments operating under trust frameworks that require pre-
registered credential queries (for example, EUDI and the Swiss Trust
Framework) MUST NOT advertise "dcql_query_supported" as true. An RP
that sends a "dcql_query" to such an OP will receive an
"invalid_request" error per Section 4.1.2. An RP MUST consult the
OP's discovery metadata (see Section 5.2) to determine whether the
DCQL-based mode is supported before including a "dcql_query".
Scopes identify which credentials to collect; the "dcql_query"
member, when present, refines how they are collected. If only scopes
are present, the OP applies its pre-registered mapping for each
scope.
4.1.1. Scope-Based Requests
The following is a non-normative example of a scope-based request (no
"claims" parameter). The RP requests EHIC and PDA1 credentials using
the OP's pre-registered mapping:
GET /authorize?
response_type=code
&scope=openid ehic pda1
&client_id=https://rp.example.org
&redirect_uri=https://rp.example.org/cb
&nonce=n-0S6_WzA2Mj HTTP/1.1
Svensson, et al. Expires 25 February 2027 [Page 5]
Internet-Draft Credential to OIDC Bridge August 2026
The requested scopes directly correlate to the keys used in the
Credential Set returned by the OP. For example, if the RP requests
scopes "ehic" and "pda1", the resulting Credential Set contains
"ehic" and "pda1" entries.
In scope-based mode the RP cannot express selective disclosure, value
constraints, or issuer restrictions on a per-request basis; the OP
applies its own policy. RPs that need such control MAY use the DCQL-
based mode (Section 4.1.2) where supported by the OP.
4.1.2. DCQL-Based Requests
An RP MAY supply a "dcql_query" member inside the OIDC "claims"
request parameter as permitted by Section 5.5.1 of [OpenID.Core].
The "dcql_query" value MUST be a DCQL query object as defined in
Section 6 of [OpenID4VP], restricted to the profile defined in this
section.
An OP that supports the DCQL-based mode MUST advertise this in its
discovery metadata via "dcql_query_supported" (see Section 5.2). If
the OP does not support the DCQL-based mode and the RP supplies a
"dcql_query", the OP MUST return an OIDC error response with error
code "invalid_request".
The "dcql_query" value is a DCQL query object as defined in Section 6
of [OpenID4VP]. All member definitions, required and optional
fields, and format-specific rules (e.g., for the "meta" object of
dc+sd-jwt and mso_mdoc) are inherited from that section and are not
restated here.
This profile applies the following additional restrictions:
* The DCQL "claim_sets" member MUST NOT be used; express claim
alternation via multiple Credential Queries linked from
"credential_sets".
* Each Credential Query MUST identify a credential type (via
"format" and the format-specific type identifier in "meta") that
matches an entry in "credential_presentations_supported" whose
scope value is present in the authorization request. Otherwise
the OP MUST return "invalid_request".
* Credential Query "id" values are opaque to the OP (per Section 6
of [OpenID4VP]) and are used only as response keys and as
references from "credential_sets".
* When "claims" is omitted, the OP applies the pre-registered claim
set of the matched entry.
Svensson, et al. Expires 25 February 2027 [Page 6]
Internet-Draft Credential to OIDC Bridge August 2026
The "credential_sets" member expresses combinatorial logic over
Credential Queries as defined in Section 6.3 of [OpenID4VP]. Each
Credential Set entry contains an "options" array listing alternative
AND-groups of Credential Query "id"s, plus an OPTIONAL "id" and
OPTIONAL "required" boolean (default true). If "credential_sets" is
present, the OP MUST evaluate the alternation per Section 6.3 of
[OpenID4VP] and return, for each satisfied Credential Set, one
Credential Set object within the "presented_credentials" claim (see
Section 5.1.1) whose members are the Credential Queries in the
matched AND-group. The OPTIONAL "id" of the Credential Set entry MAY
be echoed by the OP in the response to help the RP identify which
alternative was satisfied (see Section 5.1.1).
If "credential_sets" is absent, the OP treats all Credential Queries
as required, matching the DCQL default behaviour.
Trusted authority handling:
* When a Credential Query includes "trusted_authorities", the OP
MUST only accept a credential for that query if it chains to at
least one of the listed authorities. Credentials that do not
chain to any listed authority MUST be treated as not satisfying
the query.
* If "trusted_authorities" is absent, the OP applies its own issuer
policy.
* Security requirements for dereferencing external trust list
references (e.g., "etsi_tl", "openid_federation") are given in
Section 7.4.
The following is a non-normative example requesting a PID from a
specific pair of trusted authorities using the OpenID Federation
authority type:
Svensson, et al. Expires 25 February 2027 [Page 7]
Internet-Draft Credential to OIDC Bridge August 2026
{
"id_token": {
"dcql_query": {
"credentials": [
{
"id": "pid",
"format": "dc+sd-jwt",
"meta": {
"vct_values": ["urn:eu.europa.ec.eudi:pid:1"]
},
"claims": [
{"path": ["family_name"]},
{"path": ["given_name"]},
{"path": ["birth_date"]}
],
"trusted_authorities": [
{
"type": "openid_federation",
"values": [
"https://pid.example.gov.se",
"https://pid.example.gov.no"
]
}
]
}
]
}
}
}
The following is a non-normative example using an ETSI Trust List to
accept PID and EHIC credentials from any issuer recognised by the
list, without enumerating each issuer individually:
Svensson, et al. Expires 25 February 2027 [Page 8]
Internet-Draft Credential to OIDC Bridge August 2026
{
"id_token": {
"dcql_query": {
"credentials": [
{
"id": "pid",
"format": "dc+sd-jwt",
"meta": {"vct_values": ["urn:eu.europa.ec.eudi:pid:1"]},
"claims": [
{"path": ["family_name"]},
{"path": ["birth_date"]}
],
"trusted_authorities": [
{
"type": "etsi_tl",
"values": ["https://trust.eu.example.org/tsl.xml"]
}
]
},
{
"id": "ehic",
"format": "dc+sd-jwt",
"meta": {"vct_values": ["urn:eu.europa.ec.eudi:ehic:1"]},
"claims": [
{"path": ["ehic_number"]}
],
"trusted_authorities": [
{
"type": "etsi_tl",
"values": ["https://trust.eu.example.org/tsl.xml"]
}
]
}
]
}
}
}
The following is a non-normative example expressing "PID AND EHIC
together":
Svensson, et al. Expires 25 February 2027 [Page 9]
Internet-Draft Credential to OIDC Bridge August 2026
{
"id_token": {
"dcql_query": {
"credentials": [
{
"id": "pid",
"format": "dc+sd-jwt",
"meta": {"vct_values": ["urn:eu.europa.ec.eudi:pid:1"]},
"claims": [{"path": ["family_name"]}]
},
{
"id": "ehic",
"format": "dc+sd-jwt",
"meta": {"vct_values": ["urn:eu.europa.ec.eudi:ehic:1"]},
"claims": [{"path": ["ehic_number"]}]
}
],
"credential_sets": [
{
"id": "pid_and_ehic",
"options": [["pid", "ehic"]]
}
]
}
}
}
The following is a non-normative example expressing "PID OR EHIC"
using two alternatives. Only the AND-group that was satisfied
appears in the corresponding Credential Set in the response:
Svensson, et al. Expires 25 February 2027 [Page 10]
Internet-Draft Credential to OIDC Bridge August 2026
{
"id_token": {
"dcql_query": {
"credentials": [
{
"id": "pid",
"format": "dc+sd-jwt",
"meta": {"vct_values": ["urn:eu.europa.ec.eudi:pid:1"]},
"claims": [{"path": ["family_name"]}]
},
{
"id": "ehic",
"format": "dc+sd-jwt",
"meta": {"vct_values": ["urn:eu.europa.ec.eudi:ehic:1"]},
"claims": [{"path": ["ehic_number"]}]
}
],
"credential_sets": [
{
"id": "pid_or_ehic",
"options": [["pid"], ["ehic"]]
}
]
}
}
}
The following is a non-normative example expressing "PID required,
EHIC nice-to-have" using two Credential Sets, one required and one
optional:
Svensson, et al. Expires 25 February 2027 [Page 11]
Internet-Draft Credential to OIDC Bridge August 2026
{
"id_token": {
"dcql_query": {
"credentials": [
{
"id": "pid",
"format": "dc+sd-jwt",
"meta": {"vct_values": ["urn:eu.europa.ec.eudi:pid:1"]},
"claims": [{"path": ["family_name"]}]
},
{
"id": "ehic",
"format": "dc+sd-jwt",
"meta": {"vct_values": ["urn:eu.europa.ec.eudi:ehic:1"]},
"claims": [{"path": ["ehic_number"]}]
}
],
"credential_sets": [
{"id": "pid_required", "options": [["pid"]], "required": true},
{"id": "ehic_optional", "options": [["ehic"]], "required": false}
]
}
}
}
The following is a non-normative example applying a value constraint
on "age_over_18":
{
"id_token": {
"dcql_query": {
"credentials": [
{
"id": "pid",
"format": "dc+sd-jwt",
"meta": {"vct_values": ["urn:eu.europa.ec.eudi:pid:1"]},
"claims": [
{"path": ["family_name"]},
{"path": ["age_over_18"], "values": [true]}
]
}
]
}
}
}
The following is a non-normative example requesting nested claims
from a PID credential:
Svensson, et al. Expires 25 February 2027 [Page 12]
Internet-Draft Credential to OIDC Bridge August 2026
{
"id_token": {
"dcql_query": {
"credentials": [
{
"id": "pid",
"format": "dc+sd-jwt",
"meta": {"vct_values": ["urn:eu.europa.ec.eudi:pid:1"]},
"claims": [
{"path": ["family_name"]},
{"path": ["address", "street_address"]},
{"path": ["address", "country"], "values": ["SE"]}
]
}
]
}
}
}
If the wallet presents multiple credentials matching a single
Credential Query (e.g., two EHICs for different family members), the
OP returns all of them in the corresponding array within the
Credential Set. 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).
4.2. Consuming Credential Claims
The "presented_credentials" claim structure is defined in
Section 5.1. The RP MUST parse the claim according to that
definition.
Credential authenticity, holder binding, revocation status, and
enforcement of any DCQL constraints supplied by the RP are the
responsibility of the OP (see Section 4.3); the RP does not re-verify
the credential. The "verification" object and other validation-
related metadata returned by the OP (see Section 5.1.2) are
informational: the RP MAY use them as inputs to its own business
logic, policy engine, or audit records. How the RP uses that
metadata is a matter of local policy and out of scope for this
specification, except where noted for "verification.crit" in
Section 5.1.2.
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.
Svensson, et al. Expires 25 February 2027 [Page 13]
Internet-Draft Credential to OIDC Bridge August 2026
2. Parse the "presented_credentials" array and extract the
Credential Set objects relevant to its use case.
3. Not assume that all requested scopes will be present in the
response; the user may have declined to present certain
credentials.
4. Except for members listed in "verification.crit", ignore
unrecognised credential keys and unrecognised members within
Credential Entry objects.
4.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).
4.4. Liability and Accountability
The bridge architecture shifts credential verification responsibility
from the RP to the OP. This has implications for liability that
deployments MUST consider.
The OP is the sole party that interacts with the wallet and verifies
credential authenticity, revocation status, and holder binding. The
RP relies entirely on the OP's assertion that the credential claims
are valid. If the OP incorrectly accepts a forged, expired, or
revoked credential, the RP has no independent means of detecting
this.
Deployments SHOULD establish clear agreements between the OP operator
and RPs that address:
* The OP's obligations regarding credential verification (e.g.,
which trust frameworks it enforces, whether it checks revocation).
* Liability allocation when the OP accepts a credential that turns
out to be invalid or fraudulent.
* The OP's obligations to communicate changes to its verification
policy that may affect RP authorization decisions.
* Audit and logging requirements that allow after-the-fact review of
verification decisions.
Svensson, et al. Expires 25 February 2027 [Page 14]
Internet-Draft Credential to OIDC Bridge August 2026
The "verification" metadata in the Credential Entry (Section 5.1.2)
provides a technical mechanism for the OP to communicate verification
details to the RP. However, the "verification" object does not
constitute a legal guarantee. RPs operating in regulated
environments (e.g., healthcare, finance) SHOULD require contractual
assurances from the OP in addition to the technical signals provided
by this specification.
5. OpenID Provider Requirements
5.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:
{
"iss": "https://issuer.example.org",
"sub": "user@example.org",
"iat": 1722772800,
"exp": 1722859200,
"presented_credentials": [
{
"ehic": [
{
"type": ["https://credential.example.org/ehic/1.0"],
"issuer": "https://svs.example.se",
"valid_from": 1709251200,
"valid_until": 1740787200,
"verified_at": 1722772700,
"verification": {
"trust_status": "not_checked",
"holder_binding": "key_binding"
},
"claims": {
"name": "John Doe",
"dob": "1990-01-01",
"ehic_number": "1234567890"
}
}
],
"pda1": [
{
"type": ["https://credential.example.org/pda1/1.0"],
"issuer": "https://tax.example.se",
"valid_from": 1709251200,
"valid_until": 1740787200,
"verified_at": 1722772700,
Svensson, et al. Expires 25 February 2027 [Page 15]
Internet-Draft Credential to OIDC Bridge August 2026
"verification": {
"trust_status": "not_checked",
"holder_binding": "key_binding"
},
"claims": {
"name": "John Doe",
"dob": "1990-01-01",
"pda1_number": "0987654321",
"employer": {
"name": "Example Corp AB",
"country": "SE"
}
}
}
]
}
]
}
5.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 whose members are either credential
entries (each key a scope value in scope-based mode, or a DCQL
Credential Query "id" in DCQL-based mode, with the value being a JSON
array of Credential Entry objects as defined in Section 5.1.2), or
the reserved member described below.
The following reserved member MAY be present at the top level of a
Credential Set:
id OPTIONAL string. When the RP used the DCQL-based mode
(Section 4.1.2) and supplied a "credential_sets" entry with an
"id", the OP MAY echo that "id" here to allow the RP to identify
which Credential Set was satisfied. The value is chosen by the RP
and treated as opaque by the OP; for example, an RP that asked for
"PID or EHIC" via a "credential_sets" entry with "id":
"pid_or_ehic" receives the same string back on the corresponding
Credential Set in the response. The reserved name "id" MUST NOT
be used as a credential type scope value (i.e., as a key in
"credential_presentations_supported") nor as a DCQL Credential
Query identifier.
Svensson, et al. Expires 25 February 2027 [Page 16]
Internet-Draft Credential to OIDC Bridge August 2026
Within a Credential Set:
* Each non-reserved key MUST be unique.
* Each non-reserved 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 via "credential_sets" in the DCQL-based
mode (see Section 4.1). In that case the OP MUST return one
Credential Set object per satisfied DCQL Credential Set entry, in the
same order as they appeared in the request.
Additional members within a Credential Set MAY be present.
Implementations that do not recognise additional members MUST ignore
them.
5.1.2. Credential Entry Object
Each Credential Entry object represents a single credential presented
during the presentation flow. It MUST contain the following members:
type A non-empty JSON array of strings identifying the credential
type. The array contents are credential-format specific:
* For SD-JWT VC credentials the array contains a single element:
the Verifiable Credential Type (vct).
* For ISO mdoc credentials the array contains a single element:
the docType.
* For W3C Verifiable Credentials the array is the credential's
"type" array, preserving the order in the credential.
* For other formats the array contains the type identifier(s)
that the credential format defines, preserving any ordering
defined by that format. Single-value formats produce a one-
element array.
The OP MUST set this field based on the presented credential.
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.
Svensson, et al. Expires 25 February 2027 [Page 17]
Internet-Draft Credential to OIDC Bridge August 2026
It MAY contain the following additional members:
issuer A string identifying the entity that issued the credential.
For SD-JWT VC credentials this is the "iss" claim value, for mdoc
credentials it is the issuing authority identifier. The OP SHOULD
populate this field to allow the RP to make issuer-aware
authorization decisions.
namespace A string identifying the credential-format-specific
namespace to which the disclosed claims belong. This member is
intended for formats that scope claims by namespace, such as ISO
mdoc, where its value corresponds to the mdoc NameSpace
identifier. For credential formats that do not use namespaces
this member MUST NOT be present.
valid_from A NumericDate (as defined in [RFC7519]) indicating when
the credential became valid (i.e., the issuance or activation
date).
valid_until A NumericDate indicating when the credential expires.
The OP MAY include credentials whose "valid_until" is in the past
at the time of presentation; in that case the OP MUST set the
"trust_status" member of the "verification" object to "expired"
(see Section 8.3) so that the RP can act on the signal. Whether
to accept an expired credential is outside the scope of this
specification and is governed by deployment policy, the applicable
trust framework, and any agreements between the OP and the RP.
verified_at A NumericDate indicating when the OP verified the
credential during the presentation flow. This allows the RP to
assess the freshness of the verification relative to its own
requirements.
verification A JSON object providing metadata about the verification
the OP performed on the credential. The OP MUST include the
"verification" object in every Credential Entry. If the OP did
not perform a trust-status check, it MUST set "trust_status" to
"not_checked" (see Section 8.3); other members of "verification"
MAY be omitted when the corresponding information is unavailable.
This object MAY contain the following members:
holder_binding A string describing the mechanism used to verify
that the presenter is the legitimate holder of the credential.
Values are taken from the "Credential Holder Binding Methods"
registry defined in Section 8.4.
trust_status A string describing the OP's assessment of the
Svensson, et al. Expires 25 February 2027 [Page 18]
Internet-Draft Credential to OIDC Bridge August 2026
credential's trust status at the time of verification. Values
are taken from the "Credential Trust Status Values" registry
defined in Section 8.3. If the OP did not perform a trust-
status check, the OP MUST set this member to "not_checked"
rather than omitting it. If the OP performed a check but the
authoritative source returned no conclusive answer, the OP MUST
set this member to "unknown".
protected_headers A JSON object echoing selected verified
protected-header parameters from the underlying credential
(e.g., JOSE "alg", "kid", "x5c", or COSE protected headers for
mdoc). The OP MUST populate this member exclusively from
headers that were covered by the credential's signature
verification and MUST NOT include unverified data. The set of
parameters included is a deployment decision.
crit A JSON array of non-empty strings, each naming another
member of the same "verification" object that the RP MUST
understand to accept the credential. Semantics are modelled
after the "crit" Header Parameter of Section 4.1.11 of RFC
7515. If the RP does not recognise every member listed in
"crit", or does not understand the semantics assigned to the
listed member's value, the RP MUST treat the credential as not
satisfying the request. Values listed in "crit" MUST also
appear as members of the "verification" object; the string
"crit" itself MUST NOT appear in the array. This mechanism
allows the OP to ensure that safety-critical signals (e.g., a
"trust_status" of "suspended") cannot be silently ignored.
Additional members within the "verification" object MAY be
present. Unless listed in "crit", implementations that do not
recognise additional members MUST ignore them.
The following is a non-normative example of a Credential Entry with
nested claims and an extended "verification" object, as might appear
in a PID credential whose trust status the OP wants the RP to
acknowledge:
Svensson, et al. Expires 25 February 2027 [Page 19]
Internet-Draft Credential to OIDC Bridge August 2026
{
"type": ["urn:eu.europa.ec.eudi:pid:1"],
"issuer": "https://pid.example.gov.se",
"valid_from": 1709251200,
"valid_until": 1740787200,
"verified_at": 1722772700,
"verification": {
"holder_binding": "key_binding",
"trust_status": "suspended",
"protected_headers": {
"alg": "ES256",
"kid": "pid-signer-2026"
},
"crit": ["trust_status"]
},
"claims": {
"family_name": "Doe",
"given_name": "John",
"birth_date": "1990-01-01",
"address": {
"street_address": "123 Main St",
"locality": "Stockholm",
"postal_code": "11122",
"country": "SE"
},
"age_over_18": true,
"nationalities": [
"SE",
"NO"
]
}
}
The following is a non-normative example of a Credential Entry for a
W3C Verifiable Credential where "type" is an array:
Svensson, et al. Expires 25 February 2027 [Page 20]
Internet-Draft Credential to OIDC Bridge August 2026
{
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://university.example.edu",
"verified_at": 1722772700,
"verification": {
"trust_status": "not_checked",
"holder_binding": "key_binding"
},
"claims": {
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
}
}
Additional members MAY be present. Implementations that do not
recognise additional members MUST ignore them.
5.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 MUST include a "credential_presentations_supported" member in
its discovery metadata. This is a JSON object where each key is a
scope value that the RP can use in the authorization request, and
each value is an object describing the credential type configuration.
Each configuration object MUST contain at minimum:
format A string identifying the credential format (e.g., "dc+sd-
jwt", "mso_mdoc").
type A string identifying the credential type. For SD-JWT VC
credentials this is the vct value; for mdoc credentials this is
the docType.
The OP uses this metadata to translate the RP's scope request into
the correct credential query (e.g., a DCQL query with the appropriate
"vct_values" or "doctype_value") toward the wallet. The Credential
Entry "type" array in the response MUST be populated from the
presented credential itself and MUST contain the "type" value
declared in this mapping.
Svensson, et al. Expires 25 February 2027 [Page 21]
Internet-Draft Credential to OIDC Bridge August 2026
An OP that additionally supports the DCQL-based request mode
(Section 4.1.2) MUST include a JSON boolean member
"dcql_query_supported" in its discovery metadata with the value true.
An OP that does not support the DCQL-based mode MAY omit this member
or set it to false.
The following is a non-normative example of an RP discovering the
OP's supported credential types:
GET /.well-known/openid-configuration HTTP/1.1
Host: op.example.org
HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer": "https://op.example.org",
"authorization_endpoint": "https://op.example.org/authorize",
"token_endpoint": "https://op.example.org/token",
"userinfo_endpoint": "https://op.example.org/userinfo",
"jwks_uri": "https://op.example.org/jwks.json",
"credential_presentations_supported": {
"ehic": {
"format": "dc+sd-jwt",
"type": "urn:eu.europa.ec.eudi:ehic:1"
},
"pda1": {
"format": "dc+sd-jwt",
"type": "urn:eu.europa.ec.eudi:pda1:1"
}
}
}
5.3. Authentication Flow
When the OP receives an OIDC Authentication Request that includes
credential type scopes (and optionally a "dcql_query" member inside
the OIDC "claims" request parameter for fine-grained control), it
MUST:
1. Validate that each credential type scope corresponds to a key in
the OP's "credential_presentations_supported" metadata. The OP
MUST ignore any credential type scope that is not present in its
metadata. If none of the requested credential scopes are
supported, the OP MUST return an OIDC error response.
Svensson, et al. Expires 25 February 2027 [Page 22]
Internet-Draft Credential to OIDC Bridge August 2026
2. If the request includes a "dcql_query" member, validate it
against the profile defined in Section 4.1.2. If the OP does not
support the DCQL-based mode, or the query does not conform to the
profile, the OP MUST return an OIDC error response with error
code "invalid_request".
3. Initiate a credential presentation request to the user's wallet
for the supported credential types, using the presentation
protocol supported by the deployment. When the RP supplied a
"dcql_query", the OP SHOULD translate it into the corresponding
presentation-protocol query (see Appendix A for the DCQL
binding).
4. Verify the presented credentials according to the applicable
trust framework, including any "trusted_authorities" constraints
from the RP's "dcql_query".
5. Extract the disclosed claims from each verified credential.
6. Construct the "presented_credentials" object as defined in
Section 5.1.1.
7. 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.
5.4. Credential Mapping
This section describes the protocol-agnostic mapping between the
OIDC-level request the RP sends to the OP and the credential data the
OP returns. Concrete bindings to specific presentation protocols are
given in the appendices; the DCQL binding used with OpenID4VP is
defined in Appendix A, and a placeholder for a future DIDComm binding
appears in Appendix B.
The OP uses the "credential_presentations_supported" discovery
metadata to translate scopes into credential queries. For each
credential type scope in the authorization request, the OP looks up
the corresponding key in "credential_presentations_supported" and
uses the "format" and "type" values to construct the presentation-
protocol query. The same key is used both to identify the credential
in the query toward the wallet and as the key in the
"presented_credentials" response.
Svensson, et al. Expires 25 February 2027 [Page 23]
Internet-Draft Credential to OIDC Bridge August 2026
The binding is:
* The key in "credential_presentations_supported" (e.g., "ehic") is
the scope value the RP includes in the authorization request, and
MUST also be used as the Credential Query identifier in the
presentation-protocol query.
* The OP MUST use the "format" and "type" from the configuration
entry to populate the presentation-protocol query's format and
type-identifier parameters.
* The OP MUST use this same value as the key in the
"presented_credentials" response object. For example, if the RP
requested scope "ehic", the resulting Credential Set entry MUST be
keyed as "ehic".
When the RP additionally supplied a "dcql_query" in the OIDC "claims"
request parameter (Section 4.1.2), the OP MUST use the RP-chosen
Credential Query "id" values as the keys in the
"presented_credentials" response. Correlation to
"credential_presentations_supported" is by credential type, per
Section 4.1.2.
Response construction rules:
* The OP MUST NOT include claims that were not disclosed by the
wallet.
* The OP MUST NOT modify claim values during the mapping.
* When the RP used the DCQL-based mode and specified a non-empty
"claims" array for a Credential Query, the OP MUST include only
the requested claims in the corresponding Credential Entry's
"claims" object. Even if the wallet discloses additional claims
(for example, because the credential format does not support
selective disclosure), the OP MUST NOT relay unrequested claims to
the RP. This ensures data minimization regardless of the
underlying credential format's selective disclosure capabilities.
* When the RP used scope-based mode, or the RP's Credential Query
omitted "claims", the OP includes the claim set configured for
that credential type by deployment policy.
Constraint enforcement rules:
Svensson, et al. Expires 25 February 2027 [Page 24]
Internet-Draft Credential to OIDC Bridge August 2026
* If a claim query in the RP's "dcql_query" specifies a "values"
array and the disclosed claim value does not match any entry
(using the matching rules in Appendix C), the credential MUST be
treated as not satisfying the query.
* If the RP's "dcql_query" specifies "trusted_authorities" for a
Credential Query and the presented credential does not chain to at
least one listed authority, the credential MUST be treated as not
satisfying the query. Security requirements for dereferencing
external trust material are given in Section 7.4.
* If the RP's "dcql_query" includes "credential_sets", the OP MUST
evaluate the alternation per Section 6.3 of [OpenID4VP]. If no
required Credential Set can be satisfied, the OP MUST return an
OIDC error response (e.g., "access_denied").
Applicability of RP-supplied constraints:
* In scope-based mode the RP cannot express selective-disclosure,
value, or issuer constraints on a per-request basis; the OP
applies its own policy.
* In DCQL-based mode the RP can express selective disclosure via
"path", value constraints via "values", and issuer or authority
constraints via "trusted_authorities", within the profile defined
in Section 4.1.2.
* Constraints not expressible in this profile (for example, issuance
date filters or compound field requirements) remain deployment
policy. The OP SHOULD document 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.
6. Limitations and Considerations
Svensson, et al. Expires 25 February 2027 [Page 25]
Internet-Draft Credential to OIDC Bridge August 2026
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.
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.
Svensson, et al. Expires 25 February 2027 [Page 26]
Internet-Draft Credential to OIDC Bridge August 2026
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. Fresh Presentation Requirement
Each OIDC Authentication Request that includes credential scopes MUST
result in a new credential presentation from the wallet. The OP MUST
initiate a fresh presentation protocol transaction (e.g., OpenID4VP,
DIDComm) for every authentication request and MUST NOT reuse
credentials from a previous presentation.
The OP MUST NOT store, cache, or persist credential data beyond the
scope of the current authentication transaction. Once the OP has
constructed the ID Token or UserInfo response and delivered it to the
RP, it MUST discard the credential claims. This ensures that
credential freshness is guaranteed and that the OP does not become an
unnecessary repository of sensitive personal data.
6.5. 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).
Svensson, et al. Expires 25 February 2027 [Page 27]
Internet-Draft Credential to OIDC Bridge August 2026
* _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.
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. Security Considerations
7.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.
The RP MUST validate standard JWT claims ("iat", "exp", "nonce") in
the ID Token to ensure freshness of the "presented_credentials"
claim.
7.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).
7.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.
Svensson, et al. Expires 25 February 2027 [Page 28]
Internet-Draft Credential to OIDC Bridge August 2026
7.4. Trust Authority Dereferencing
When the OP dereferences external references contained in a
"trusted_authorities" entry supplied via the RP's "dcql_query" (such
as an "etsi_tl" trust list URI or an "openid_federation" entity
identifier), it MUST enforce the following safeguards:
* The OP MUST only fetch external trust material over HTTPS.
* The OP MUST NOT dereference arbitrary URIs provided by an RP. The
OP MUST restrict which URIs it is willing to fetch to prevent
Server-Side Request Forgery (SSRF). The mechanism for this
restriction (e.g., an allowlist, domain policy) is a deployment
decision and outside the scope of this specification.
* The OP MUST impose size limits on fetched documents to prevent
resource exhaustion.
* The OP SHOULD cache dereferenced trust material and enforce a
minimum refresh interval to limit the impact of a compromised or
unavailable remote trust material source.
* If an external trust reference cannot be fetched or parsed, the OP
MUST treat that "trusted_authorities" entry as contributing no
authorities. Other entries in the same "trusted_authorities"
array that were successfully resolved still apply. The OP MUST
NOT treat an unresolved entry as matching all authorities.
7.5. 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.
Svensson, et al. Expires 25 February 2027 [Page 29]
Internet-Draft Credential to OIDC Bridge August 2026
8. 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.
8.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 a
credential presentation flow, structured for consumption by OIDC
Relying Parties.
Change Controller IETF
Specification Document(s) Section 5.1.1 of this document
8.2. OpenID Connect Discovery Metadata Registration
This specification requests registration of the following metadata
parameters:
Metadata Name "credential_presentations_supported"
Metadata Description A JSON object describing the credential types
the OP can collect via credential presentation and expose as OIDC
claims.
Change Controller IETF
Specification Document(s) Section 5.2 of this document
Metadata Name "dcql_query_supported"
Metadata Description A JSON boolean indicating whether the OP
accepts a "dcql_query" member inside the OIDC "claims" request
parameter as defined in the DCQL-based request mode.
Change Controller IETF
Specification Document(s) Section 5.2 of this document
Svensson, et al. Expires 25 February 2027 [Page 30]
Internet-Draft Credential to OIDC Bridge August 2026
8.3. Credential Trust Status Values Registry
This specification establishes the "Credential Trust Status Values"
registry. The registration policy is "Specification Required" as
defined in Section 4.6 of [RFC8126].
Each entry in the registry contains the following fields:
Value A short string used as the value of the "trust_status" member
of the Credential Entry "verification" object.
Description A brief description of the trust-status semantics.
Change Controller The entity responsible for the registration.
Specification Document(s) Reference to the specification defining
the value.
The initial contents of the registry are:
Svensson, et al. Expires 25 February 2027 [Page 31]
Internet-Draft Credential to OIDC Bridge August 2026
+=============+=======================+============+===============+
| Value | Description | Change | Specification |
| | | Controller | |
+=============+=======================+============+===============+
| not_checked | The OP performed no | IETF | Section 5.1.2 |
| | trust-status check | | of this |
| | for this credential | | document |
+-------------+-----------------------+------------+---------------+
| unknown | The OP performed a | IETF | Section 5.1.2 |
| | trust-status check | | of this |
| | but the authoritative | | document |
| | source returned no | | |
| | conclusive answer | | |
| | (e.g., ETSI Token | | |
| | Status List "unknown" | | |
| | state) | | |
+-------------+-----------------------+------------+---------------+
| valid | The credential's | IETF | Section 5.1.2 |
| | trust status was | | of this |
| | checked and is | | document |
| | currently valid | | |
+-------------+-----------------------+------------+---------------+
| suspended | The credential is | IETF | Section 5.1.2 |
| | temporarily suspended | | of this |
| | by its issuer or | | document |
| | trust framework | | |
+-------------+-----------------------+------------+---------------+
| revoked | The credential has | IETF | Section 5.1.2 |
| | been revoked by its | | of this |
| | issuer or trust | | document |
| | framework | | |
+-------------+-----------------------+------------+---------------+
| expired | The credential has | IETF | Section 5.1.2 |
| | expired according to | | of this |
| | its own validity | | document |
| | period | | |
+-------------+-----------------------+------------+---------------+
| invalid | The credential failed | IETF | Section 5.1.2 |
| | one or more | | of this |
| | verification checks | | document |
+-------------+-----------------------+------------+---------------+
Table 1
Svensson, et al. Expires 25 February 2027 [Page 32]
Internet-Draft Credential to OIDC Bridge August 2026
8.4. Credential Holder Binding Methods Registry
This specification establishes the "Credential Holder Binding
Methods" registry. The registration policy is "Specification
Required" as defined in Section 4.6 of [RFC8126].
Each entry in the registry contains the following fields:
Method Name A short string identifying the holder binding method.
Description A brief description of the method.
Change Controller The entity responsible for the registration.
Specification Document(s) Reference to the specification defining
the method.
The initial contents of the registry are:
+=============+========================+============+===============+
| Method Name | Description | Change | Specification |
| | | Controller | |
+=============+========================+============+===============+
| key_binding | Cryptographic proof | IETF | Section 5.1.2 |
| | of possession of a | | of this |
| | private key bound | | document |
| | to the credential | | |
+-------------+------------------------+------------+---------------+
| biometric | Biometric | IETF | Section 5.1.2 |
| | verification of the | | of this |
| | presenter against | | document |
| | data bound to the | | |
| | credential | | |
+-------------+------------------------+------------+---------------+
| pin | Verification of a | IETF | Section 5.1.2 |
| | PIN or passcode | | of this |
| | known to the | | document |
| | credential holder | | |
+-------------+------------------------+------------+---------------+
Table 2
9. References
9.1. Normative References
Svensson, et al. Expires 25 February 2027 [Page 33]
Internet-Draft Credential to OIDC Bridge August 2026
[OpenID4VP]
Terbu, O., Lodderstedt, T., Yasuda, K., and T. Looker,
"OpenID for Verifiable Presentations (OpenID4VP) 1.0",
2024, <https://openid.net/specs/openid-4-verifiable-
presentations-1_0.html>.
[OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., Medeiros, B. de.,
and C. Mortimore, "OpenID Connect Core 1.0", November
2014,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Discovery 1.0", November 2014,
<https://openid.net/specs/openid-connect-discovery-
1_0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
9.2. Informative References
[ISO.18013-5]
ISO/IEC, "Personal identification -- ISO-compliant driving
licence -- Part 5: Mobile driving licence (mDL)
application", 2021,
<https://www.iso.org/standard/69084.html>.
Svensson, et al. Expires 25 February 2027 [Page 34]
Internet-Draft Credential to OIDC Bridge August 2026
[SD-JWT.VC]
Terbu, O. and D. Fett, "SD-JWT-based Verifiable
Credentials (SD-JWT VC)", 2024,
<https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-
vc-05.html>.
Appendix A. DCQL Binding
This appendix defines the concrete binding between the OIDC-level
request defined in Section 4.1 and DCQL as specified in Section 6 of
[OpenID4VP]. Deployments that use OpenID4VP as the presentation
protocol between the OP and the wallet MUST follow this binding;
other bindings are out of scope of this appendix.
A.1. Scope-Based Mode
For each credential type scope in the authorization request, the OP
constructs one DCQL Credential Query as follows:
* The scope value is used verbatim as the DCQL Credential Query
"id".
* The "format" is taken from the corresponding entry in
"credential_presentations_supported".
* The "meta" member is populated from the entry's "type": for the
dc+sd-jwt format the OP sets meta.vct_values to a JSON array
containing the "type" string; for the mso_mdoc format the OP sets
meta.doctype_value to the "type" string.
* The "claims" array is either omitted or set to the deployment's
pre-registered claim set for the credential type.
For example, given the discovery metadata:
{
"credential_presentations_supported": {
"ehic": {
"format": "dc+sd-jwt",
"type": "urn:eu.europa.ec.eudi:ehic:1"
},
"pda1": {
"format": "dc+sd-jwt",
"type": "urn:eu.europa.ec.eudi:pda1:1"
}
}
}
Svensson, et al. Expires 25 February 2027 [Page 35]
Internet-Draft Credential to OIDC Bridge August 2026
and an RP request with scope=openid ehic pda1, the OP constructs the
following DCQL query:
{
"credentials": [
{
"id": "ehic",
"format": "dc+sd-jwt",
"meta": {
"vct_values": ["urn:eu.europa.ec.eudi:ehic:1"]
}
},
{
"id": "pda1",
"format": "dc+sd-jwt",
"meta": {
"vct_values": ["urn:eu.europa.ec.eudi:pda1:1"]
}
}
]
}
The wallet returns a VP Token keyed by these same "id" values,
allowing the OP to map presented credentials back to the
corresponding scope.
A.2. DCQL-Based Mode
When the RP supplied a "dcql_query" member in the OIDC "claims"
request parameter, the OP MUST use that query as the DCQL query sent
to the wallet, subject to the following:
* RP-supplied Credential Query "id" values are forwarded to the
wallet unchanged.
* Each Credential Query MUST satisfy the type and scope checks of
Section 4.1.2; otherwise the OP MUST reject the request.
* The OP MUST augment the query with Credential Queries derived from
any requested scopes not already covered, using the scope-based
rules above, and MUST NOT reuse an "id" supplied by the RP.
* The OP MUST NOT relax any constraint expressed by the RP (e.g.,
MUST NOT drop "trusted_authorities" or widen "values").
Svensson, et al. Expires 25 February 2027 [Page 36]
Internet-Draft Credential to OIDC Bridge August 2026
A.3. Response Mapping
For each satisfied Credential Query, the OP populates a Credential
Entry as defined in Section 5.1.2. The DCQL Credential Query "id"
becomes the key in the enclosing Credential Set in the
"presented_credentials" response.
When the RP's "dcql_query" contains "credential_sets", the OP returns
one Credential Set object in the "presented_credentials" array for
each satisfied entry in "credential_sets", populated with the
Credential Entries from the matched AND-group. The OPTIONAL "id" of
each Credential Set entry MAY be echoed in the response via the
reserved "id" member described in Section 5.1.1.
A.4. Value Constraint Propagation
DCQL value matching is defined as best-effort: the wallet SHOULD
filter on the constraint but is not required to do so (see
Section 6.4.1 of [OpenID4VP]). Consequently, the OP MUST NOT rely on
the wallet to enforce "values" constraints and MUST always validate
disclosed claim values against the RP's "values" requirements after
receiving the presentation. Propagating the constraint to the wallet
remains useful as a privacy optimisation, because it allows the
wallet to avoid disclosing credentials that would not satisfy the
request.
Appendix B. DIDComm Binding
This appendix is reserved for a future DIDComm Present Proof binding.
Its inclusion is intended to make the extension pattern explicit:
bindings for additional presentation protocols may be added here
without changing the protocol-agnostic contract in Section 5.4.
Appendix C. Claim Value Matching
Several normative rules in this specification require comparing a
disclosed claim value against entries in a "values" array. A
disclosed value matches an entry if and only if both are of the same
JSON type (as defined in [RFC8259]) and are equal under the following
rules:
* Strings are compared as sequences of Unicode code points. No
Unicode normalization, case folding, or whitespace trimming is
applied.
* Numbers are compared by mathematical value, independent of their
lexical representation (for example, 1, 1.0, and 1e0 all match).
Svensson, et al. Expires 25 February 2027 [Page 37]
Internet-Draft Credential to OIDC Bridge August 2026
* Boolean values match only the identical boolean, and the null
value matches only null.
Values of different JSON types never match (for example, the string
"1" does not match the number 1). Objects and arrays are not
expected in "values" entries; if present, they MUST be compared
structurally, with member and element equality determined recursively
by these same rules and object member order treated as insignificant.
Acknowledgments
The author would like to thank Patrick Amrein (Ubique) for reviews,
comments, and contributions to this document.
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 25 February 2027 [Page 38]