Certificate Authentication Context Type for OpenID Connect
draft-santesson-oidc-cert-auth-context-01
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 | Stefan Santesson , Martin Lindstrom | ||
| Last updated | 2026-10-21 | ||
| 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-santesson-oidc-cert-auth-context-01
Network Working Group S. Santesson
Internet-Draft M. Lindstrom
Updates: 7773 (if approved) IDsec Solutions
Intended status: Standards Track 22 October 2026
Expires: 25 April 2027
Certificate Authentication Context Type for OpenID Connect
draft-santesson-oidc-cert-auth-context-01
Abstract
RFC 7773 defines the Authentication Context certificate extension,
which carries information about how the subject of an X.509
certificate was authenticated when the certificate was issued. RFC
7773 defines one context information type, for subjects authenticated
by means of a Security Assertion Markup Language (SAML) assertion.
This document defines a second context information type for subjects
authenticated by means of OpenID Connect, where the identity
information is obtained from an ID Token, where applicable in
combination with a UserInfo Response. The information is expressed
as a JSON object and provides the OpenID Connect counterpart to the
SAML Authentication Context Information defined in RFC 7773.
This document also updates RFC 7773 by clarifying that an application
processing the extension ignores context information types it does
not support regardless of the criticality of the extension, and by
recommending that the extension not be marked critical.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://swedenconnect.github.io/ietf-rfc7773-oidc-auth-context/draft-
santesson-oidc-certificate-authentication-context.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-santesson-oidc-cert-auth-
context/.
Source for this draft and an issue tracker can be found at
https://github.com/swedenconnect/ietf-rfc7773-oidc-auth-context.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Santesson & Lindstrom Expires 25 April 2027 [Page 1]
Internet-Draft OIDC Cert Auth Context October 2026
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 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. OpenID Connect Authentication Context Information . . . . . . 4
3.1. Context Type Identifier . . . . . . . . . . . . . . . . . 5
3.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. JSON Structure . . . . . . . . . . . . . . . . . . . . . 5
3.4. Claim Mapping . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Relationship to the ID Token and UserInfo Response . . . 9
4. Updates to RFC 7773 . . . . . . . . . . . . . . . . . . . . . 9
4.1. Processing of Unsupported Context Types . . . . . . . . . 9
4.2. Criticality . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Trust in the Recorded Information . . . . . . . . . . . . 11
5.2. Authentication Context Class References . . . . . . . . . 11
5.3. Authentication Methods References . . . . . . . . . . . . 11
5.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Ignoring Unsupported Context Types . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. X.509 Authentication Context Types Registry . . . . . . . 13
Santesson & Lindstrom Expires 25 April 2027 [Page 2]
Internet-Draft OIDC Cert Auth Context October 2026
6.2. IETF URN Sub-namespace Registration . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Example OACI Object . . . . . . . . . . . . . . . . . . . 15
A.2. Example Certificates . . . . . . . . . . . . . . . . . . 16
A.2.1. Certificate with the Members in Common Use . . . . . 16
A.2.2. Certificate with All Members and Additional
Members . . . . . . . . . . . . . . . . . . . . . . . 18
Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The Authentication Context certificate extension [RFC7773] allows a
Certification Authority (CA) to record, in an issued certificate,
information about the authentication event that preceded issuance.
This is useful when the CA relies on an external identity provider to
authenticate the subject, for example when certificates are issued on
the fly to support electronic signatures, and relying parties need to
understand the origin and assurance of the identity data placed in
the certificate.
The extension is a sequence of AuthenticationContext structures, each
identified by a contextType URI that also determines the syntax of
the accompanying contextInfo string. [RFC7773] defines one context
type, Security Assertion Markup Language (SAML) Authentication
Context Information (SACI), for subjects authenticated by a SAML
assertion, and explicitly provides for other documents to define
additional context types.
OpenID Connect [OIDC.Core] has become a widely deployed alternative
to SAML for federated authentication. An OpenID Connect
authentication results in an ID Token, a JSON Web Token (JWT)
[RFC7519] containing claims about the authentication event and the
authenticated End-User. Further claims about the End-User may be
obtained from the UserInfo Endpoint of the OpenID Provider. This
document defines OpenID Connect Authentication Context Information
(OACI), a context type whose contextInfo is a JSON object [RFC8259]
carrying the information from the ID Token and, where applicable, the
UserInfo Response that is relevant to the issuance of a certificate.
Santesson & Lindstrom Expires 25 April 2027 [Page 3]
Internet-Draft OIDC Cert Auth Context October 2026
OACI is deliberately structured as the OpenID Connect analogue of
SACI. It records the issuer of the ID Token, the time of
authentication, the authentication context class(es) asserted, a
reference to the ID Token, the identity under which the CA acted as
Relying Party, and a mapping from ID Token claims to the subject name
attributes of the certificate that were derived from them.
OACI is defined using the extensibility provided by Section 2 of
[RFC7773]. With a second context type in existence, the processing
rule in [RFC7773] that ties the handling of unsupported context types
to the criticality of the extension becomes an obstacle to
interoperability: an application that implements only SACI would be
required to reject a certificate carrying OACI in a critical
extension, although the two convey the same kind of information.
This document therefore also updates [RFC7773] as described in
Section 4.
2. 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.
This document uses the terms OpenID Provider (OP), Relying Party
(RP), End-User, ID Token, Claim, UserInfo Endpoint and UserInfo
Response as defined in [OIDC.Core].
The RP of the OpenID Connect authentication is either the CA that
issues the certificate or a Registration Authority (RA) acting on
behalf of the CA, such as a signing service that authenticates the
End-User and then requests a certificate from the CA, conveying the
authentication information with the request. For brevity, this
document refers to the CA as the RP; where an RA performs the
authentication, statements about the CA's handling of the ID Token
and UserInfo Response apply to the RA, and the CA is responsible for
the information under its certificate policy and practices.
The terms contextType, contextInfo and AuthenticationContext refer to
the ASN.1 components defined in Section 2 of [RFC7773].
3. OpenID Connect Authentication Context Information
Santesson & Lindstrom Expires 25 April 2027 [Page 4]
Internet-Draft OIDC Cert Auth Context October 2026
3.1. Context Type Identifier
An AuthenticationContext carrying OpenID Connect Authentication
Context Information in accordance with this specification MUST have a
contextType with the following URI value:
urn:ietf:params:x509-auth-context:oidc
The contextInfo component of such an AuthenticationContext MUST be
present and MUST contain a JSON object as specified in Section 3.3.
3.2. Encoding
The contextInfo value is a UTF8String [RFC7773]. Its content MUST be
a single JSON text [RFC8259] whose top-level value is an object. The
JSON text MUST conform to the I-JSON message format [RFC7493]. In
particular, it MUST be encoded in UTF-8, MUST NOT begin with a byte
order mark, and MUST NOT contain duplicate member names.
Producers SHOULD serialize the object without insignificant
whitespace in order to limit certificate size. Consumers MUST accept
any serialization that is valid I-JSON.
Consumers MUST ignore members of the top-level object, and of the
objects in the claim_mappings array, that they do not recognize.
This allows future documents and deployment profiles to add members
without breaking existing implementations.
3.3. JSON Structure
The top-level object contains the members defined below. The member
names are chosen for readability by a reader of the certificate;
where a member corresponds to an ID Token claim, the correspondence
is stated. Unless otherwise specified, a member is OPTIONAL. This
document places no requirement on the presence of any member whose
source value is itself optional in [OIDC.Core]. Deployment profiles
of this document MAY require the presence of specific members, and
relying parties decide which members they require in order to accept
a certificate.
iss: REQUIRED. String. The Issuer Identifier of the OpenID
Provider that authenticated the End-User, as given by the iss
claim of the ID Token. This is a URL using the https scheme with
no query or fragment component, as specified in Section 2 of
[OIDC.Core]. This member corresponds to the IdentityProvider
attribute of SACI.
auth_time: Number. The time at which the End-User authentication
Santesson & Lindstrom Expires 25 April 2027 [Page 5]
Internet-Draft OIDC Cert Auth Context October 2026
occurred, as given by the auth_time claim of the ID Token. The
value is a NumericDate as defined in Section 2 of [RFC7519]: the
number of seconds from 1970-01-01T00:00:00Z UTC until the time of
authentication, ignoring leap seconds, expressed as a JSON number.
This member corresponds to the AuthenticationInstant attribute of
SACI.
acr: String. The Authentication Context Class Reference of the
authentication, as given by the acr claim of the ID Token. This
member corresponds to the AuthnContextClassRef attribute of SACI.
amr: Array of strings. The Authentication Methods References of the
authentication, as given by the amr claim of the ID Token. Values
are as registered in the "Authentication Method Reference Values"
registry established by [RFC8176], or values defined by agreement
between the OP and the RP. The array MUST contain at least one
element when present. This member has no counterpart in SACI.
See Section 5.3 for the relationship between this member and acr.
jti: String. A unique identifier of the ID Token, as given by the
jti claim of the ID Token. This member corresponds to the
AssertionRef attribute of SACI. Note that jti is OPTIONAL in an
ID Token.
sub: String. The Subject Identifier of the End-User at the OpenID
Provider, as given by the sub claim of the ID Token. Together
with iss, client_id and auth_time, this member allows the
authentication event to be located in the records of the OpenID
Provider, which is of particular use when the ID Token carried no
jti claim. The value is opaque to the CA and to relying parties,
and may be a pairwise identifier that is specific to the
client_id. This member has no counterpart in SACI. See
Section 5.4 for considerations on including this member.
client_id: String. The OAuth 2.0 client identifier under which the
CA acted as Relying Party towards the OpenID Provider. This value
appears as an audience of the ID Token (the aud claim). This
member corresponds to the ServiceID attribute of SACI.
claim_mappings: Array of objects. Each object describes how one
claim about the End-User, obtained from the ID Token or from the
UserInfo Response, was used to populate a subject name attribute
in the certificate. The structure of each object is defined in
Section 3.4. This member corresponds to the IdAttributes element
of SACI. The array MUST contain at least one element when
present.
Santesson & Lindstrom Expires 25 April 2027 [Page 6]
Internet-Draft OIDC Cert Auth Context October 2026
3.4. Claim Mapping
A claim mapping object records that the value of a certificate
subject name attribute was derived from an End-User claim. In
contrast to SACI, the claim value itself is not repeated in the
mapping; the value is present in the certificate attribute to which
the mapping refers.
Each claim mapping object contains the following members:
type: REQUIRED. String. One of the values rdn, san or sda, with
the meaning defined for the Type attribute in Section 3.1.2 of
[RFC7773]:
* rdn - an attribute in a Relative Distinguished Name of the
certificate subject field.
* san - a name in the Subject Alternative Name extension.
* sda - an attribute in the Subject Directory Attributes
extension.
ref: REQUIRED. String. Identifies the certificate attribute or
name form, with the same content rules as the Ref attribute in
Section 3.1.2 of [RFC7773]:
* For type rdn and sda, the object identifier of the attribute
type, in dotted-decimal notation (a sequence of decimal
integers separated by periods, with no other characters).
* For type san, the decimal tag number of the GeneralName choice,
e.g. 1 for rfc822Name and 2 for dNSName. For the otherName
choice, the object identifier of the type-id in dotted-decimal
notation.
claim: REQUIRED. String. A JSON Pointer [RFC6901] identifying the
claim within the set of claims about the End-User, where the root
of the pointer is the ID Token claims set (or the UserInfo
Response, see source). For a standard top-level claim this is
simply / followed by the claim name, e.g. /given_name. The
pointer form allows reference to members of structured claims,
e.g. /address/street_address, and to claims in aggregated or
distributed claim sets.
source: String. Indicates where the claim was obtained. The value
id_token indicates the ID Token; the value userinfo indicates the
UserInfo Response. When absent, the default value is id_token.
Santesson & Lindstrom Expires 25 April 2027 [Page 7]
Internet-Draft OIDC Cert Auth Context October 2026
A single certificate attribute MAY be derived from more than one
claim, in which case several claim mapping objects share the same
type and ref values. A single claim MAY be mapped to more than one
certificate attribute. Appendix A.1 shows a set of claim mappings
for a typical certificate subject.
3.5. Schema
The following schema, expressed in YAML using the vocabulary of
[JSON-SCHEMA], is a normative statement of the structure defined in
Section 3.3 and Section 3.4. In case of conflict between the prose
and the schema, the prose takes precedence.
$schema: "https://json-schema.org/draft/2020-12/schema"
$id: "urn:ietf:params:x509-auth-context:oidc"
title: OpenID Connect Authentication Context Information
type: object
required: [iss]
properties:
iss:
type: string
format: uri
auth_time:
type: number
minimum: 0
acr:
type: string
amr:
type: array
minItems: 1
items:
type: string
jti:
type: string
sub:
type: string
client_id:
type: string
claim_mappings:
type: array
minItems: 1
items:
$ref: "#/$defs/claimMapping"
$defs:
claimMapping:
type: object
required: [type, ref, claim]
properties:
Santesson & Lindstrom Expires 25 April 2027 [Page 8]
Internet-Draft OIDC Cert Auth Context October 2026
type:
type: string
enum: [rdn, san, sda]
ref:
type: string
pattern: "^[0-9]+(\\.[0-9]+)*$"
claim:
type: string
format: json-pointer
source:
type: string
enum: [id_token, userinfo]
default: id_token
Unrecognized members are permitted everywhere; the schema
intentionally does not set additionalProperties to false.
3.6. Relationship to the ID Token and UserInfo Response
The OACI object is produced by the CA from an ID Token, and where
applicable a UserInfo Response, that the CA has validated according
to Sections 3.1.3.7 and 5.3.4 of [OIDC.Core]. The OACI object is not
itself a token: it carries no signature and no exp or iat members,
because its integrity and lifetime are those of the certificate in
which it is embedded. A relying party that wishes to inspect the
original ID Token may use the iss, client_id and jti members to
locate it, if the CA retains tokens according to its practices.
4. Updates to RFC 7773
4.1. Processing of Unsupported Context Types
Section 2 of [RFC7773] states that an application that finds an
authentication context information type it does not understand MUST
ignore it if the extension is non-critical and MUST reject the
certificate if the extension is marked critical.
Santesson & Lindstrom Expires 25 April 2027 [Page 9]
Internet-Draft OIDC Cert Auth Context October 2026
This rule conflates two separate matters: whether an application
recognizes the Authentication Context extension, which is what the
criticality flag of [RFC5280] governs, and how an application that
does recognize the extension treats individual AuthenticationContext
entries. The information carried by the extension is descriptive.
It allows a relying party that cares about the origin of the
subject's identity to evaluate it against its own policy, but it
requires no action from a relying party that does not. Requiring
every relying party to support every context type present in a
certificate therefore serves no security purpose, and it prevents a
CA from including several context types in one certificate, for
example to serve both legacy applications and new applications that
support different versions of the same information.
Accordingly, the rule is replaced by the following.
An application that recognizes the Authentication Context extension
MUST be able to parse the AuthenticationContexts structure. It
processes each AuthenticationContext entry whose contextType it
supports according to the specification of that context type, and
MUST ignore each AuthenticationContext entry whose contextType it
does not support. This applies irrespective of whether the extension
is marked critical.
The criticality flag of the extension retains only its meaning under
Section 4.2 of [RFC5280]: an application that does not recognize the
Authentication Context extension at all MUST reject a certificate in
which the extension is marked critical.
4.2. Criticality
Section 2 of [RFC7773] states that the extension MAY be marked
critical.
Since the extension carries descriptive information and mandates no
action by a relying party, marking it critical excludes relying
parties that do not implement the extension without providing any
corresponding benefit. This document updates [RFC7773] as follows:
the Authentication Context extension SHOULD NOT be marked critical.
5. Security Considerations
The security considerations of [RFC7773] apply.
Santesson & Lindstrom Expires 25 April 2027 [Page 10]
Internet-Draft OIDC Cert Auth Context October 2026
5.1. Trust in the Recorded Information
The information in an OACI object is asserted by the CA, not by the
OpenID Provider. The CA, or an RA acting on its behalf, copies
values from an ID Token and UserInfo Response that it validated at
the time of issuance; a relying party has no means of re-validating
these from the certificate alone. A relying party therefore trusts
the OACI content to exactly the extent that it trusts the CA, as
expressed in the CA's certificate policy and practices. Where an RA
performs the authentication, the CA's trust in the RA, and the means
by which the authentication information is conveyed from the RA to
the CA, are matters for the CA's practices and are outside the scope
of this document.
5.2. Authentication Context Class References
The value of the acr member is only meaningful within the trust
framework that defines it. A relying party MUST NOT infer an
assurance level from an acr value defined by a framework it does not
recognize.
5.3. Authentication Methods References
The amr member is informative. As noted in Section 4 of [RFC8176],
amr values are asserted by the OP without any standardized means of
verification and are not a substitute for an authentication context
class. The member is provided so that the concrete methods used can
be recorded for audit and troubleshooting, and because amr values,
unlike acr values, are drawn from a public registry and remain
interpretable outside the originating trust framework.
The acr and amr members are complementary, not alternatives: acr is
the OP's statement of the assurance achieved, and amr describes the
methods used to achieve it. When both are present, acr governs. A
relying party MUST NOT use amr values to raise or lower the assurance
it attributes to the acr value, and SHOULD NOT base an assurance
decision solely on amr values when acr is absent. An apparent
inconsistency between the two, for example an acr value denoting a
high assurance level together with amr values denoting a single weak
factor, is a matter between the OP and the trust framework that
governs it, and is not resolved by the relying party.
Santesson & Lindstrom Expires 25 April 2027 [Page 11]
Internet-Draft OIDC Cert Auth Context October 2026
5.4. Privacy
An OACI object reveals the identity of the OP that authenticated the
subject, the time of authentication and, through claim_mappings,
which identity attributes in the certificate were asserted by that
OP. Together with the certificate serial number and jti, this allows
a certificate to be correlated with an authentication event logged at
the OP and the CA. CAs SHOULD include only members needed by the
intended relying parties, and deployment profiles SHOULD consider
whether jti and auth_time are required.
The sub member is a persistent identifier of the End-User at the
OpenID Provider. When the OpenID Provider issues pairwise Subject
Identifiers (see Section 8 of [OIDC.Core]), the value is specific to
the client_id and cannot be used to correlate the End-User across
Relying Parties. When the OpenID Provider issues public Subject
Identifiers, the value is the same for every Relying Party of that
OpenID Provider, and including it in a certificate allows anyone
holding the certificate to correlate its subject with the End-User's
accounts at other Relying Parties of the same OpenID Provider. A CA
SHOULD include sub only where the ability to locate the
authentication record is needed by the intended relying parties, and
deployment profiles SHOULD state whether sub is included and under
which Subject Identifier type.
Beyond sub, this document defines no member carrying End-User claim
values. The claim values that were placed in the certificate are
present in the certificate subject name; repeating them would
increase the personal data carried by the certificate without adding
information a relying party can verify.
5.5. Ignoring Unsupported Context Types
Under Section 4.1, an application silently ignores context types it
does not support. A relying party whose policy requires
authentication context information of a particular type must
therefore check for the presence of that type explicitly and treat
its absence according to policy; the absence of a supported entry is
not an error condition in itself.
6. IANA Considerations
Santesson & Lindstrom Expires 25 April 2027 [Page 12]
Internet-Draft OIDC Cert Auth Context October 2026
6.1. X.509 Authentication Context Types Registry
IANA is requested to create a new registry titled "X.509
Authentication Context Types" under a new "X.509 Authentication
Context" registry group. The registry lists the URIs defined for use
as contextType values in the Authentication Context certificate
extension [RFC7773], together with the specification that defines the
syntax of the corresponding contextInfo.
The registration policy is Specification Required (see [RFC8126]).
Each entry contains:
* Context Type URI: the URI used as the contextType value.
* Description: a short description of the context information type.
* Reference: the specification defining the contextInfo syntax.
Context type URIs are not required to be assigned under the Uniform
Resource Name (URN) sub-namespace registered in Section 6.2; any URI
under the control of the registrant is acceptable. Registrations
under the URN sub-namespace are expected to be made by IETF
documents.
The initial content of the registry is:
+========================================+==============+==========+
| Context Type URI |Description |Reference |
+========================================+==============+==========+
| http://id.elegnamnden.se/auth- |SAML |[RFC7773],|
| cont/1.0/saci |Authentication|Section 3 |
| |Context | |
| |Information | |
+----------------------------------------+--------------+----------+
| urn:ietf:params:x509-auth-context:oidc |OpenID Connect|This |
| |Authentication|document, |
| |Context |Section 3 |
| |Information | |
+----------------------------------------+--------------+----------+
Table 1: Initial registry content
6.2. IETF URN Sub-namespace Registration
IANA is requested to register the following entry in the "IETF URN
Sub-namespace for Registered Protocol Parameter Identifiers" registry
established by [RFC3553]:
Santesson & Lindstrom Expires 25 April 2027 [Page 13]
Internet-Draft OIDC Cert Auth Context October 2026
Registry name: x509-auth-context
Specification: This document.
Repository: The "X.509 Authentication Context Types" registry
(Section 6.1).
Index value: The index value is the string following the prefix
urn:ietf:params:x509-auth-context:. Values are registered as
complete URIs in the "X.509 Authentication Context Types"
registry; the entries of that registry beginning with the prefix
constitute the values of this sub-namespace.
7. References
7.1. Normative References
[OIDC.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 2", December 2023,
<https://openid.net/specs/openid-connect-core-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>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <https://www.rfc-editor.org/rfc/rfc3553>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer", RFC 6901,
DOI 10.17487/RFC6901, April 2013,
<https://www.rfc-editor.org/rfc/rfc6901>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/rfc/rfc7493>.
Santesson & Lindstrom Expires 25 April 2027 [Page 14]
Internet-Draft OIDC Cert Auth Context October 2026
[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>.
[RFC7773] Santesson, S., "Authentication Context Certificate
Extension", RFC 7773, DOI 10.17487/RFC7773, March 2016,
<https://www.rfc-editor.org/rfc/rfc7773>.
[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>.
7.2. Informative References
[JSON-SCHEMA]
Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON
Schema: A Media Type for Describing JSON Documents", June
2022,
<https://json-schema.org/draft/2020-12/json-schema-core>.
[RFC8176] Jones, M., Hunt, P., and A. Nadalin, "Authentication
Method Reference Values", RFC 8176, DOI 10.17487/RFC8176,
June 2017, <https://www.rfc-editor.org/rfc/rfc8176>.
Appendix A. Examples
A.1. Example OACI Object
The following OACI object records an authentication performed by the
OpenID Provider https://op.example.com on 2026-10-19 at 13:04:05 UTC,
satisfying the authentication context class https://example.com/loa/3
of an example trust framework. The Signature Service
https://sign.example.com acted as Relying Party. The certificate
subject name contains the End-User's personal identity number
(serialNumber, OID 2.5.4.5), given name (OID 2.5.4.42), surname (OID
2.5.4.4) and full name (commonName, OID 2.5.4.3), all derived from ID
Token claims, and an email address in the Subject Alternative Name
extension derived from the UserInfo Response.
Santesson & Lindstrom Expires 25 April 2027 [Page 15]
Internet-Draft OIDC Cert Auth Context October 2026
{
"iss": "https://op.example.com",
"auth_time": 1792415045,
"acr": "https://example.com/loa/3",
"jti": "0f3e2c6a-7b1d-4e4c-9a2e-5d1c2b3a4f60",
"client_id": "https://sign.example.com",
"claim_mappings": [
{ "type": "rdn", "ref": "2.5.4.5",
"claim": "/https:~1~1example.com~1claims~1personal_id" },
{ "type": "rdn", "ref": "2.5.4.42", "claim": "/given_name" },
{ "type": "rdn", "ref": "2.5.4.4", "claim": "/family_name" },
{ "type": "rdn", "ref": "2.5.4.3", "claim": "/name" },
{ "type": "san", "ref": "1", "claim": "/email",
"source": "userinfo" }
]
}
Note that the first mapping refers to a claim whose name is itself a
URI. Since / is the reference token separator in a JSON Pointer, the
/ characters inside the claim name are escaped as ~1 (see Section 3
of [RFC6901]).
[[ Editor's note: claims with URI names are common in national
profiles and the escaping makes them hard to read. Consider instead
a plain claim name in claim with a separate OPTIONAL path member (a
JSON Pointer relative to the claim) for members of structured claims.
]]
A.2. Example Certificates
The two certificates below were issued with an Authentication Context
extension carrying OpenID Connect Authentication Context Information
(OACI). They differ only in the content of that extension, which in
both cases is non-critical and holds a single AuthenticationContext
entry with contextType urn:ietf:params:x509-auth-context:oidc and, as
contextInfo, the compact serialization of the OACI object shown.
A.2.1. Certificate with the Members in Common Use
The OACI object of this certificate uses the members that are
expected to be present in most deployments.
Santesson & Lindstrom Expires 25 April 2027 [Page 16]
Internet-Draft OIDC Cert Auth Context October 2026
{
"iss": "https://op.example.com",
"auth_time": 1792415045,
"acr": "https://example.com/loa/3",
"jti": "0f3e2c6a-7b1d-4e4c-9a2e-5d1c2b3a4f60",
"client_id": "https://sign.example.com",
"claim_mappings": [
{ "type": "rdn", "ref": "2.5.4.5",
"claim": "/https:~1~1example.com~1claims~1personal_id" },
{ "type": "rdn", "ref": "2.5.4.42", "claim": "/given_name" },
{ "type": "rdn", "ref": "2.5.4.4", "claim": "/family_name" },
{ "type": "rdn", "ref": "2.5.4.3", "claim": "/name" },
{ "type": "san", "ref": "1", "claim": "/email",
"source": "userinfo" }
]
}
-----BEGIN CERTIFICATE-----
MIIEojCCBEigAwIBAgIQaRxBgrAzhqBLxgMNLE2zYDAKBggqhkjOPQQDAjA8MQsw
CQYDVQQGEwJTRTEUMBIGA1UECgwLRXhhbXBsZSBPcmcxFzAVBgNVBAMMDkV4YW1w
bGUgT3JnIENBMB4XDTI2MTAyMTIzMDIyNVoXDTI3MTAyMTIzMDI0MFowajELMAkG
A1UEBhMCU0UxFDASBgNVBAoMC0V4YW1wbGUgT3JnMRUwEwYDVQQFEwwxOTgwMDEw
MTEyMzQxDTALBgNVBCoMBEpvaG4xDDAKBgNVBAQMA0RvZTERMA8GA1UEAwwISm9o
biBEb2UwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQTl0XWg1uw3OslF5AfJpKG
8TARrdlKG2K1UfxBsA/OzRlVwUjRy18XfIygQH5lOY1blWv6OtoXCjy2/OFDHQW+
o4IC/DCCAvgwKwYDVR0jBCQwIoAg6PyStPn2O6tUxxpIlfXhU1PJcAxJsaxJ0gD7
/gkPlBowKQYDVR0OBCIEIEClxJat0Be942HTTEcbjIAAlNDpH0SSYJMYYBMH4/OR
MA4GA1UdDwEB/wQEAwIGQDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vZXhhbXBs
ZS5jb20vY3JsL2V4YW1wbGUtb3JnLWNhLmNybDCCAi8GByqFcIFJBQEEggIiMIIC
HjCCAhoMJnVybjppZXRmOnBhcmFtczp4NTA5LWF1dGgtY29udGV4dDpvaWRjDIIB
7nsiaXNzIjoiaHR0cHM6Ly9vcC5leGFtcGxlLmNvbSIsImF1dGhfdGltZSI6MTc5
MjQxNTA0NSwiYWNyIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9sb2EvMyIsImp0aSI6
IjBmM2UyYzZhLTdiMWQtNGU0Yy05YTJlLTVkMWMyYjNhNGY2MCIsImNsaWVudF9p
ZCI6Imh0dHBzOi8vc2lnbi5leGFtcGxlLmNvbSIsImNsYWltX21hcHBpbmdzIjpb
eyJ0eXBlIjoicmRuIiwicmVmIjoiMi41LjQuNSIsImNsYWltIjoiL2h0dHBzOn4x
fjFleGFtcGxlLmNvbX4xY2xhaW1zfjFwZXJzb25hbF9pZCJ9LHsidHlwZSI6InJk
biIsInJlZiI6IjIuNS40LjQyIiwiY2xhaW0iOiIvZ2l2ZW5fbmFtZSJ9LHsidHlw
ZSI6InJkbiIsInJlZiI6IjIuNS40LjQiLCJjbGFpbSI6Ii9mYW1pbHlfbmFtZSJ9
LHsidHlwZSI6InJkbiIsInJlZiI6IjIuNS40LjMiLCJjbGFpbSI6Ii9uYW1lIn0s
eyJ0eXBlIjoic2FuIiwicmVmIjoiMSIsImNsYWltIjoiL2VtYWlsIiwic291cmNl
IjoidXNlcmluZm8ifV19MB8GA1UdEQQYMBaBFGpvaG4uZG9lQGV4YW1wbGUuY29t
MAoGCCqGSM49BAMCA0gAMEUCICU+oZK3P988RzZAG1ndwJH1wa7WDLkdFn97SkOs
Eb3BAiEA7H2AAwKNCpZkxa4eQYCKIONWquPaeX8VYoMC4sCiGLg=
-----END CERTIFICATE-----
Santesson & Lindstrom Expires 25 April 2027 [Page 17]
Internet-Draft OIDC Cert Auth Context October 2026
A.2.2. Certificate with All Members and Additional Members
The OACI object of this certificate uses every member defined in this
document, including amr, sub and an explicit source on the first
claim mapping, together with two additional members defined by the
issuer, one with a string value and one with a boolean value. The
additional members follow the members defined by this document.
{
"iss": "https://op.example.com",
"auth_time": 1792415045,
"acr": "https://example.com/loa/3",
"amr": ["sc", "pin"],
"jti": "0f3e2c6a-7b1d-4e4c-9a2e-5d1c2b3a4f60",
"sub": "a1b2c3d4e5f60718293a4b5c6d7e8f90",
"client_id": "https://sign.example.com",
"claim_mappings": [
{ "type": "rdn", "ref": "2.5.4.5",
"claim": "/https:~1~1example.com~1claims~1personal_id",
"source": "id_token" },
{ "type": "rdn", "ref": "2.5.4.42", "claim": "/given_name" },
{ "type": "rdn", "ref": "2.5.4.4", "claim": "/family_name" },
{ "type": "rdn", "ref": "2.5.4.3", "claim": "/name" },
{ "type": "san", "ref": "1", "claim": "/email",
"source": "userinfo" }
],
"https://example.com/claims/transaction_id": "dc6ac7656H89bfb51",
"https://example.com/claims/sign_message_displayed": true
}
Santesson & Lindstrom Expires 25 April 2027 [Page 18]
Internet-Draft OIDC Cert Auth Context October 2026
-----BEGIN CERTIFICATE-----
MIIFbDCCBRKgAwIBAgIRAI7QprHdV9BqCt2MTUNg3NgwCgYIKoZIzj0EAwIwPDEL
MAkGA1UEBhMCU0UxFDASBgNVBAoMC0V4YW1wbGUgT3JnMRcwFQYDVQQDDA5FeGFt
cGxlIE9yZyBDQTAeFw0yNjEwMjEyMzAyMjVaFw0yNzEwMjEyMzAyNDBaMGoxCzAJ
BgNVBAYTAlNFMRQwEgYDVQQKDAtFeGFtcGxlIE9yZzEVMBMGA1UEBRMMMTk4MDAx
MDExMjM0MQ0wCwYDVQQqDARKb2huMQwwCgYDVQQEDANEb2UxETAPBgNVBAMMCEpv
aG4gRG9lMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEE5dF1oNbsNzrJReQHyaS
hvEwEa3ZShtitVH8QbAPzs0ZVcFI0ctfF3yMoEB+ZTmNW5Vr+jraFwo8tvzhQx0F
vqOCA8UwggPBMCsGA1UdIwQkMCKAIOj8krT59jurVMcaSJX14VNTyXAMSbGsSdIA
+/4JD5QaMCkGA1UdDgQiBCBApcSWrdAXveNh00xHG4yAAJTQ6R9EkmCTGGATB+Pz
kTAOBgNVHQ8BAf8EBAMCBkAwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2V4YW1w
bGUuY29tL2NybC9leGFtcGxlLW9yZy1jYS5jcmwwggL4BgcqhXCBSQUBBIIC6zCC
AucwggLjDCZ1cm46aWV0ZjpwYXJhbXM6eDUwOS1hdXRoLWNvbnRleHQ6b2lkYwyC
Ard7ImlzcyI6Imh0dHBzOi8vb3AuZXhhbXBsZS5jb20iLCJhdXRoX3RpbWUiOjE3
OTI0MTUwNDUsImFjciI6Imh0dHBzOi8vZXhhbXBsZS5jb20vbG9hLzMiLCJhbXIi
Olsic2MiLCJwaW4iXSwianRpIjoiMGYzZTJjNmEtN2IxZC00ZTRjLTlhMmUtNWQx
YzJiM2E0ZjYwIiwic3ViIjoiYTFiMmMzZDRlNWY2MDcxODI5M2E0YjVjNmQ3ZThm
OTAiLCJjbGllbnRfaWQiOiJodHRwczovL3NpZ24uZXhhbXBsZS5jb20iLCJjbGFp
bV9tYXBwaW5ncyI6W3sidHlwZSI6InJkbiIsInJlZiI6IjIuNS40LjUiLCJjbGFp
bSI6Ii9odHRwczp+MX4xZXhhbXBsZS5jb21+MWNsYWltc34xcGVyc29uYWxfaWQi
LCJzb3VyY2UiOiJpZF90b2tlbiJ9LHsidHlwZSI6InJkbiIsInJlZiI6IjIuNS40
LjQyIiwiY2xhaW0iOiIvZ2l2ZW5fbmFtZSJ9LHsidHlwZSI6InJkbiIsInJlZiI6
IjIuNS40LjQiLCJjbGFpbSI6Ii9mYW1pbHlfbmFtZSJ9LHsidHlwZSI6InJkbiIs
InJlZiI6IjIuNS40LjMiLCJjbGFpbSI6Ii9uYW1lIn0seyJ0eXBlIjoic2FuIiwi
cmVmIjoiMSIsImNsYWltIjoiL2VtYWlsIiwic291cmNlIjoidXNlcmluZm8ifV0s
Imh0dHBzOi8vZXhhbXBsZS5jb20vY2xhaW1zL3RyYW5zYWN0aW9uX2lkIjoiZGM2
YWM3NjU2SDg5YmZiNTEiLCJodHRwczovL2V4YW1wbGUuY29tL2NsYWltcy9zaWdu
X21lc3NhZ2VfZGlzcGxheWVkIjp0cnVlfTAfBgNVHREEGDAWgRRqb2huLmRvZUBl
eGFtcGxlLmNvbTAKBggqhkjOPQQDAgNIADBFAiB59kR6EPWkPpYpyy6GAPEtJvgG
u00bt8UOjQhW8ML5vgIhAITosH6WM5AgDr6dhvVqvVqZXQ07sDbX4V8/WQK8c0Q8
-----END CERTIFICATE-----
Design Notes
[[ This section is intended to be removed before publication as an
RFC. ]]
* Member names and value formats follow the ID Token claims where
there is a direct correspondence (iss, auth_time, acr, amr, jti),
so that a CA copies values without conversion, but the structure
is not a JWT claims set and is not intended to be processed as
one.
* Claim values are not repeated in claim_mappings, unlike SACI,
because they are already present in the certificate and repeating
them has not proven useful in practice.
Santesson & Lindstrom Expires 25 April 2027 [Page 19]
Internet-Draft OIDC Cert Auth Context October 2026
* The update to RFC 7773 in Section 4 is the reason this document
carries "Updates: 7773". Without it, defining a new context type
would not update RFC 7773, which already provides for additional
types.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Stefan Santesson
IDsec Solutions AB
Forskningsbyn Ideon
SE-223 70 Lund
Sweden
Email: sts@aaa-sec.com
Martin Lindstrom
IDsec Solutions AB
Forskningsbyn Ideon
SE-223 70 Lund
Sweden
Email: martin@litsec.se
Santesson & Lindstrom Expires 25 April 2027 [Page 20]