ISO/IEC 26133:2024

Information technology — OpenID connect — OpenID connect dynamic client registration 1.0 incorporating errata set 2

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. This document defines how an OpenID Connect Relying Party can dynamically register with the End-User's OpenID Provider, providing information about itself to the OpenID Provider, and obtaining information needed to use it, including the OAuth 2.0 Client ID for this Relying Party.

Titre manque

General Information

• Status: Published
• Publication Date: 30-Sep-2024
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 6060 - International Standard published
• Start Date: 01-Oct-2024
• Due Date: 14-Feb-2027
• Completion Date: 01-Oct-2024

Standards Content (Sample)

International
Standard
ISO/IEC 26133
First edition
Information technology — OpenID
2024-10
connect — OpenID connect dynamic
client registration 1.0 incorporating
errata set 2
Reference number
© ISO/IEC 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed
for the different types of document should be noted (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had
not received notice of (a) patent(s) which may be required to implement this document. However,
implementers are cautioned that this may not represent the latest information, which may be obtained
from the patent database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall
not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by the OpenID Foundation (OIDF) (as OpenID Connect Dynamic Client
Registration 1.0 incorporating errata set 2) and drafted in accordance with its editorial rules. It was
adopted, under the JTC 1 PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, Information
technology.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2024 – All rights reserved
iii
Abstract
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
protocol. It enables Clients to verify the identity of the End-User based
on the authentication performed by an Authorization Server, as well as
to obtain basic profile information about the End-User in an
interoperable and REST-like manner.
This specification defines how an OpenID Connect Relying Party can
dynamically register with the End-User's OpenID Provider, providing
information about itself to the OpenID Provider, and obtaining
information needed to use it, including the OAuth 2.0 Client ID for this
Relying Party.
© ISO/IEC 2024 – All rights reserved
iv
Table of Contents
1. Introduction
1.1. Requirements Notation and Conventions
1.2. Terminology
2. Client Metadata
2.1. Metadata Languages and Scripts
3. Client Registration Endpoint
3.1. Client Registration Request
3.2. Client Registration Response
3.3. Client Registration Error Response
4. Client Configuration Endpoint
4.1. Forming the Client Configuration Endpoint URL
4.2. Client Read Request
4.3. Client Read Response
4.4. Client Read Error Response
5. "sector_identifier_uri" Validation
6. String Operations
7. Validation
8. Implementation Considerations
8.1. Compatibility Notes
8.2. Implementation Notes on Stateless Dynamic
Client Registration
9. Security Considerations
9.1. Impersonation
9.2. Native Code Leakage
9.3. TLS Requirements
10. IANA Considerations
10.1. OAuth Dynamic Client Registration Metadata
Registration
10.1.1. Registry Contents
10.2. OAuth Token Endpoint Authentication Methods
Registration
10.2.1. Registry Contents
11. References
11.1. Normative References
11.2. Informative References
© ISO/IEC 2024 – All rights reserved
v
Information technology — OpenID Connect — OpenID
Connect Dynamic Client Registration 1.0 incorporating
errata set 2
TOC
1. Introduction
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
[RFC6749] protocol. It enables Clients to verify the identity of the End-
User based on the authentication performed by an Authorization Server,
as well as to obtain basic profile information about the End-User in an
interoperable and REST-like manner.
In order for an OpenID Connect Relying Party to utilize OpenID Connect
services for an End-User, the RP needs to register with the OpenID
Provider to provide the OP information about itself and to obtain
information needed to use it, including an OAuth 2.0 Client ID. This
specification describes how an RP can register with an OP, and how
registration information for the RP can be retrieved.
The previous versions of this specification are:
• OpenID Connect Registration 1.0 incorporating errata set
1 [OpenID.Registration.Errata1]
• OpenID Connect Registration 1.0 (final)
[OpenID.Registration.Final]
TOC
1.1. Requirements Notation and Conventions
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 RFC 2119 [RFC2119].
In the .txt version of this specification, values are quoted to indicate
that they are to be taken literally. When using these values in protocol
messages, the quotes MUST NOT be used as part of the value. In the
HTML version of this specification, values to be taken literally are
indicated by the use of this fixed-width font.
© ISO/IEC 2024 – All rights reserved
All uses of JSON Web Signature (JWS) [JWS] and JSON Web Encryption
(JWE) [JWE] data structures in this specification utilize the JWS
Compact Serialization or the JWE Compact Serialization; the JWS JSON
Serialization and the JWE JSON Serialization are not used.

TOC
1.2. Terminology
This specification uses the terms "Access Token", "Authorization Code",
"Authorization Endpoint", "Authorization Server", "Client", "Client
Authentication", "Client Identifier", "Client Secret", "Grant Type",
"Protected Resource", "Redirection URI", "Refresh Token", "Response
Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749], the
terms "JSON Web Token (JWT)" and "Nested JWT" defined by JSON
Web Token (JWT) [JWT], the term "Base64url Encoding" defined by
JSON Web Signature (JWS) [JWS], and the terms defined by OpenID
Connect Core 1.0 [OpenID.Core].
This specification defines the following additional terms:
Client Registration Endpoint
OAuth 2.0 Protected Resource through which a Client can be
registered at an Authorization Server.
Client Configuration Endpoint
OAuth 2.0 Endpoint through which registration information
for a registered Client can be managed. This URL for this
endpoint is returned by the Authorization Server in the Client
Information Response.
Registration Access Token
OAuth 2.0 Bearer Token issued by the Authorization Server
through the Client Registration Endpoint that is used to
authenticate the caller when accessing the Client's
registration information at the Client Configuration
Endpoint. This Access Token is associated with a particular
registered Client.
Initial Access Token
OAuth 2.0 Access Token optionally issued by an
Authorization Server granting access to its Client
Registration Endpoint. The contents of this token are service
specific and are out of scope for this specification. The
means by which the Authorization Server issues this token
© ISO/IEC 2024 – All rights reserved
and the means by which the Registration Endpoint validates
it are also out of scope.
IMPORTANT NOTE TO READERS: The terminology definitions in this
section are a normative portion of this specification, imposing
requirements upon implementations. All the capitalized words in the
text of this specification, such as "Client Registration Endpoint",
reference these defined terms. Whenever the reader encounters them,
their definitions found in this section must be followed.

TOC
2. Client Metadata
Clients have metadata associated with their unique Client Identifier at
the Authorization Server. These can range from human-facing display
strings, such as a Client name, to items that impact the security of the
protocol, such as the list of valid redirect URIs.
The Client Metadata values are used in two ways:
• as input values to registration requests, and
• as output values in registration responses and read
responses.
These Client Metadata values are used by OpenID Connect:
redirect_uris
REQUIRED. Array of Redirection URI values used by the
Client. One of these registered Redirection URI values MUST
exactly match the redirect_uri parameter value used in
each Authorization Request, with the matching performed as
(Simple String
described in Section 6.2.1 of [RFC3986]
Comparison).
response_types
OPTIONAL. JSON [RFC8259] array containing a list of the
OAuth 2.0 response_type values that the Client is
declaring that it will restrict itself to using. If omitted, the
default is that the Client will use only the code Response
Type.
© ISO/IEC 2024 – All rights reserved
grant_types
OPTIONAL. JSON array containing a list of the OAuth 2.0
Grant Types that the Client is declaring that it will restrict
itself to using. The Grant Type values used by OpenID
Connect are:
• authorization_code: The
Authorization Code Grant Type
described in OAuth 2.0 Section 4.1.
• implicit: The Implicit Grant Type
described in OAuth 2.0 Section 4.2.
• refresh_token: The Refresh Token
Grant Type described in OAuth 2.0
Section 6.
The following table lists the correspondence between
response_type values that the Client will use and
grant_type values that MUST be included in the registered
grant_types list:
• code: authorization_code
• id_token: implicit
• id_token token: implicit
• code id_token:
authorization_code, implicit
• code token:
authorization_code, implicit
• code id_token token:
authorization_code, implicit
If omitted, the default is that the Client will use only the
authorization_code Grant Type.
application_type
OPTIONAL. Kind of the application. The default, if omitted,
is web. The defined values are native or web. Web Clients
using the OAuth Implicit Grant Type MUST only register
URLs using the https scheme as redirect_uris; they
MUST NOT use localhost as the hostname. Native Clients
MUST only register redirect_uris using custom URI
schemes or loopback URLs using the http scheme; loopback
URLs use localhost or the IP loopback literals 127.0.0.1
or [::1] as the hostname. Authorization Servers MAY place
additional constraints on Native Clients. Authorization
Servers MAY reject Redirection URI values using the http
© ISO/IEC 2024 – All rights reserved
scheme, other than the loopback case for Native Clients. The
Authorization Server MUST verify that all the registered
redirect_uris conform to these constraints. This
prevents sharing a Client ID across different types of Clients.
contacts
OPTIONAL. Array of e-mail addresses of people responsible
for this Client. This might be used by some providers to
enable a Web user interface to modify the Client information.
client_name
OPTIONAL. Name of the Client to be presented to the End-
User. If desired, representation of this Claim in different
languages and scripts is represented as described in
Section 2.1.
logo_uri
OPTIONAL. URL that references a logo for the Client
application. If present, the server SHOULD display this
image to the End-User during approval. The value of this
field MUST point to a valid image file. If desired,
representation of this Claim in different languages and
scripts is represented as described in Section 2.1.
client_uri
OPTIONAL. URL of the home page of the Client. The value of
this field MUST point to a valid Web page. If present, the
server SHOULD display this URL to the End-User in a
followable fashion. If desired, representation of this Claim in
different languages and scripts is represented as described
in Section 2.1.
policy_uri
OPTIONAL. URL that the Relying Party Client provides to the
End-User to read about how the profile data will be used.
The value of this field MUST point to a valid web page. The
OpenID Provider SHOULD display this URL to the End-User
if it is given. If desired, representation of this Claim in
different languages and scripts is represented as described
in Section 2.1.
tos_uri
OPTIONAL. URL that the
...