RFC Errata
Found 3 records.
Status: Reported (2)
RFC 7591, "OAuth 2.0 Dynamic Client Registration Protocol", July 2015
Source of RFC: oauth (sec)
Errata ID: 7782
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tim Würtele
Date Reported: 2024-01-25
Section 3.2.1 says:
client_id
REQUIRED. OAuth 2.0 client identifier string. It SHOULD NOT be
currently valid for any other registered client, though an
authorization server MAY issue the same client identifier to
multiple instances of a registered client at its discretion.
It should say:
client_id
REQUIRED. OAuth 2.0 client identifier string. It MUST NOT be
currently valid for any other registered client, though an
authorization server MAY issue the same client identifier to
multiple instances of a registered client at its discretion.
Notes:
Allowing the same client_id for multiple clients is a contradiction to:
1. This document, Section 1.3, (D), 2nd bullet point: "a client identifier that is unique at the server"
2. This document, Section 3.1: "The authorization server assigns this client a unique client identifier"
3. (normative reference) RFC 6749, Section 2.2: "The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client. [...] The client identifier is unique to the authorization server."
4. (non-normative reference) OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2, Section 2: "Clients have metadata associated with their unique Client Identifier at the Authorization Server."; Section 3.1: "The Authorization Server assigns this Client a unique Client Identifier"; Section 3.2: "client_id REQUIRED. Unique Client Identifier. It MUST NOT be currently valid for any other registered Client. "
Errata ID: 7969
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ivan Mok
Date Reported: 2024-06-03
Section 2.3 says:
For example, a software statement could contain the following claims:
{
"software_id": "4NRB1-0XZABZI9E6-5SM3R",
"client_name": "Example Statement-based Client",
"client_uri": "https://client.example.net/"
}
The following non-normative example JWT includes these claims and has
been asymmetrically signed using "RS256" (with line breaks for
display purposes only):
eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
It should say:
For example, a software statement could contain the following claims:
{
"iss": "https://example.com",
"software_id": "4NRB1-0XZABZI9E6-5SM3R",
"client_name": "Example Statement-based Client",
"client_uri": "https://client.example.net/"
}
The following non-normative example JWT includes these claims and has
been asymmetrically signed using "RS256" (with line breaks for
display purposes only):
eyJhbGciOiJSUzI1NiJ9.<updatedPayloadWithIss>.<updatedSignature>
Notes:
Section 2.3 Software Statement says, "the software statement ... MUST contain an "iss" (issuer) claim denoting the party attesting to the claims in the software statement." It would be useful to readers if the sample software statement in the same section adheres to this condition.
If this change is reasonable, the signed JWT in section 3.1.1. Client Registration Request Using a Software Statement should also be updated.
Status: Rejected (1)
RFC 7591, "OAuth 2.0 Dynamic Client Registration Protocol", July 2015
Source of RFC: oauth (sec)
Errata ID: 8557
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Atul Tulshibagwale
Date Reported: 2025-08-27
Rejected by: RFC Editor
Date Rejected: 2025-08-28
Section 2 says:
As required by [Section 2](https://datatracker.ietf.org/doc/html/rfc7591#section-2) of OAuth 2.0 [[RFC6749](https://datatracker.ietf.org/doc/html/rfc6749)]
It should say:
As required by [Section 2](https://datatracker.ietf.org/doc/html/rfc6749#section-2) of OAuth 2.0 [[RFC6749](https://datatracker.ietf.org/doc/html/rfc6749)]
Notes:
In section 2 of RFC 7591, the links to sections 2, 2.1, 2.3.1, 4.1, 4.2, 4.3, 4.4, 4.5, and 6 are incorrectly pointing to sections within RFC7591. They should be pointing to the corresponding sections in RFC 6749. The link to sections 2.3.1, 4.3, and 4.4 are actually broken, because those sections do not exist in RFC 7591
--VERIFIER NOTES--
This is regarding the links generated in the rfc2html output, not the RFC itself (https://www.rfc-editor.org/rfc/rfc7591.txt). Please add an issue here: https://github.com/ietf-tools/rfc2html.