rfc9728v1.txt   rfc9728.txt 
skipping to change at line 112 skipping to change at line 112
The means by which the client obtains the location of the protected The means by which the client obtains the location of the protected
resource is out of scope for this document. In some cases, the resource is out of scope for this document. In some cases, the
location may be manually configured into the client; for example, an location may be manually configured into the client; for example, an
email client could provide an interface for a user to enter the URL email client could provide an interface for a user to enter the URL
of their JSON Meta Application Protocol (JMAP) server [RFC8620]. In of their JSON Meta Application Protocol (JMAP) server [RFC8620]. In
other cases, it may be dynamically discovered; for example, a user other cases, it may be dynamically discovered; for example, a user
could enter their email address into an email client, the client could enter their email address into an email client, the client
could perform WebFinger discovery [RFC7033] (in a manner related to could perform WebFinger discovery [RFC7033] (in a manner related to
the description in Section 2 of [OpenID.Discovery]) to find the the description in Section 2 of [OpenID.Discovery]) to find the
resource server, then fetch the resource server metadata to find the resource server, and the client could then fetch the resource server
authorization server to use to obtain authorization to access the metadata to find the authorization server to use to obtain
user's email. authorization to access the user's email.
The metadata for a protected resource is retrieved from a well-known The metadata for a protected resource is retrieved from a well-known
location as a JSON [RFC8259] document, which declares information location as a JSON [RFC8259] document, which declares information
about its capabilities and optionally, its relationships to other about its capabilities and, optionally, its relationships with other
services. This process is described in Section 3. services. This process is described in Section 3.
This metadata can be communicated either in a self-asserted fashion This metadata can be communicated either in a self-asserted fashion
or as a set of signed metadata values represented as claims in a JSON or as a set of signed metadata values represented as claims in a JSON
Web Token (JWT) [JWT]. In the JWT case, the issuer is vouching for Web Token (JWT) [JWT]. In the JWT case, the issuer is vouching for
the validity of the data about the protected resource. This is the validity of the data about the protected resource. This is
analogous to the role that the software statement plays in OAuth analogous to the role that the software statement plays in OAuth
dynamic client registration [RFC7591]. Dynamic Client Registration [RFC7591].
Each protected resource publishing metadata about itself makes its Each protected resource publishing metadata about itself makes its
own metadata document available at a well-known location own metadata document available at a well-known location
deterministically derived from the protected resource's URL, even deterministically derived from the protected resource's URL, even
when the resource server implements multiple protected resources. when the resource server implements multiple protected resources.
This prevents attackers from publishing metadata that supposedly This prevents attackers from publishing metadata that supposedly
describes the protected resource but that is not actually describes the protected resource but that is not actually
authoritative for the protected resource, as described in authoritative for the protected resource, as described in
Section 7.3. Section 7.3.
Section 2 defines metadata parameters that a protected resource can Section 2 defines metadata parameters that a protected resource can
publish, which includes things like which scopes are supported, how a publish, which includes things like which scopes are supported, how a
client can present an access token, and more. These values may be client can present an access token, and more. These values, such as
used by other specifications, such as the jwks_uri used to publish the jwks_uri (see Section 2), may be used with other specifications;
public keys the resource server uses to sign resource responses, for for example, the public keys published in the jwks_uri can be used to
instance, as described in [FAPI.MessageSigning]. verify the signed resource responses, as described in
[FAPI.MessageSigning].
Section 5 describes the use of WWW-Authenticate by protected Section 5 describes the use of WWW-Authenticate by protected
resources to dynamically inform clients of the URL of their protected resources to dynamically inform clients of the URL of their protected
resource metadata. This use of WWW-Authenticate can indicate that resource metadata. This use of WWW-Authenticate can indicate that
the protected resource metadata may have changed. the protected resource metadata may have changed.
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at line 166 skipping to change at line 167
All applications of JSON Web Signature (JWS) data structures [JWS] All applications of JSON Web Signature (JWS) data structures [JWS]
and JSON Web Encryption (JWE) data structures [JWE] as discussed in and JSON Web Encryption (JWE) data structures [JWE] as discussed in
this specification utilize the JWS Compact Serialization or the JWE this specification utilize the JWS Compact Serialization or the JWE
Compact Serialization; the JWS JSON Serialization and the JWE JSON Compact Serialization; the JWS JSON Serialization and the JWE JSON
Serialization are not used. Choosing a single serialization is Serialization are not used. Choosing a single serialization is
intended to facilitate interoperability. intended to facilitate interoperability.
1.2. Terminology 1.2. Terminology
This specification uses the terms "Access Token", "Authorization This specification uses the terms "access token", "authorization
Code", "Authorization Endpoint", "Authorization Grant", code", "authorization server", "client", "client authentication",
"Authorization Server", "Client", "Client Authentication", "Client "client identifier", "protected resource", and "resource server"
Identifier", "Client Secret", "Grant Type", "Protected Resource", defined by OAuth 2.0 [RFC6749], and the terms "Claim Name" and "JSON
"Redirection URI", "Refresh Token", "Resource Owner", "Resource Web Token (JWT)" defined by "JSON Web Token (JWT)" [JWT].
Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0
[RFC6749], and the terms "Claim Name", "Claim Value", and "JSON Web
Token (JWT)" defined by "JSON Web Token (JWT)" [JWT].
This specification defines the following term: This specification defines the following term:
Resource Identifier: Resource Identifier:
The protected resource's resource identifier, which is a URL that The protected resource's resource identifier, which is a URL that
uses the https scheme and has no fragment component. As specified uses the https scheme and has no fragment component. As specified
in Section 2 of [RFC8707], it also SHOULD NOT include a query in Section 2 of [RFC8707], it also SHOULD NOT include a query
component, but it is recognized that there are cases that make a component, but it is recognized that there are cases that make a
query component a useful and necessary part of a resource query component a useful and necessary part of a resource
identifier. Protected resource metadata is published at a .well- identifier. Protected resource metadata is published at a .well-
skipping to change at line 508 skipping to change at line 506
another for consistency when these lists are used by the application another for consistency when these lists are used by the application
profile. profile.
The following authorization server metadata parameter is defined by The following authorization server metadata parameter is defined by
this specification and is registered in the "OAuth Authorization this specification and is registered in the "OAuth Authorization
Server Metadata" registry established in "OAuth 2.0 Authorization Server Metadata" registry established in "OAuth 2.0 Authorization
Server Metadata" [RFC8414]. Server Metadata" [RFC8414].
protected_resources protected_resources
OPTIONAL. JSON array containing a list of resource identifiers OPTIONAL. JSON array containing a list of resource identifiers
for OAuth protected resources for protected resources that can be for OAuth protected resources that can be used with this
used with this authorization server. Authorization servers MAY authorization server. Authorization servers MAY choose not to
choose not to advertise some supported protected resources even advertise some supported protected resources even when this
when this parameter is used. In some use cases, the set of parameter is used. In some use cases, the set of protected
protected resources will not be enumerable, in which case this resources will not be enumerable, in which case this metadata
metadata parameter will not be present. parameter will not be present.
5. Use of WWW-Authenticate for Protected Resource Metadata 5. Use of WWW-Authenticate for Protected Resource Metadata
A protected resource MAY use the WWW-Authenticate HTTP response A protected resource MAY use the WWW-Authenticate HTTP response
header field, as discussed in [RFC9110], to return a URL to its header field, as discussed in [RFC9110], to return a URL to its
protected resource metadata to the client. The client can then protected resource metadata to the client. The client can then
retrieve protected resource metadata as described in Section 3. The retrieve protected resource metadata as described in Section 3. The
client might then, for instance, determine what authorization server client might then, for instance, determine what authorization server
to use for the resource based on protected resource metadata to use for the resource based on protected resource metadata
retrieved. retrieved.
A typical end-to-end flow doing so is as follows. Note that while A typical end-to-end flow doing so is as follows. Note that while
this example uses the OAuth 2.0 Authorization Code flow, a similar this example uses the OAuth 2.0 authorization code flow, a similar
sequence could also be implemented with any other OAuth flow. sequence could also be implemented with any other OAuth flow.
+----------+ +----------+ +---------------+ +----------+ +----------+ +---------------+
| Client | | Resource | | Authorization | | Client | | Resource | | Authorization |
| | | Server | | Server | | | | Server | | Server |
+----+-----+ +----+-----+ +-------+-------+ +----+-----+ +----+-----+ +-------+-------+
| | | | | |
| 1. Resource Request | | | 1. Resource Request | |
| ----------------------> | | | ----------------------> | |
| Without Access Token | | | Without Access Token | |
skipping to change at line 575 skipping to change at line 573
+-+-------------------------+------------------+-+ +-+-------------------------+------------------+-+
| | | | | |
| 10. Resource Request | | | 10. Resource Request | |
| ----------------------> | | | ----------------------> | |
| With Access Token | | | With Access Token | |
| | | | | |
| | | | | |
| 11. Resource Response | | | 11. Resource Response | |
| <---------------------- | | | <---------------------- | |
| | | | | |
+----+-----+ +----+-----+ +-------+-------+
| Client | | Resource | | Authorization |
| | | Server | | Server |
+----------+ +----------+ +---------------+
Figure 1: Sequence Diagram Figure 1: Sequence Diagram
1. The client makes a request to a protected resource without 1. The client makes a request to a protected resource without
presenting an access token. presenting an access token.
2. The resource server responds with a WWW-Authenticate header 2. The resource server responds with a WWW-Authenticate header
including the URL of the protected resource metadata. including the URL of the protected resource metadata.
3. The client fetches the protected resource metadata from this 3. The client fetches the protected resource metadata from this
URL. URL.
4. The resource server responds with the protected resource 4. The resource server responds with the protected resource
metadata according to Section 3.2. metadata according to Section 3.2.
5. The client validates the protected resource metadata, as 5. The client validates the protected resource metadata, as
described in Section 3.3. described in Section 3.3, and builds the authorization server
metadata URL from an issuer identifier in the resource metadata
according to [RFC8414].
6. The client builds the authorization server metadata URL from an 6. The client makes a request to fetch the authorization server
issuer identifier in the resource metadata according to
[RFC8414] and makes a request to fetch the authorization server
metadata. metadata.
7. The authorization server responds with the authorization server 7. The authorization server responds with the authorization server
metadata document according to [RFC8414]. metadata document according to [RFC8414].
8. The client directs the user agent to the authorization server to 8. The client directs the user agent to the authorization server to
begin the authorization flow. begin the authorization flow.
9. The authorization exchange is completed and the authorization 9. The authorization exchange is completed and the authorization
server returns an access token to the client. server returns an access token to the client.
skipping to change at line 624 skipping to change at line 626
This specification introduces a new parameter in the WWW-Authenticate This specification introduces a new parameter in the WWW-Authenticate
HTTP response header field to indicate the protected resource HTTP response header field to indicate the protected resource
metadata URL: metadata URL:
resource_metadata: resource_metadata:
The URL of the protected resource metadata. The URL of the protected resource metadata.
The response below is an example of a WWW-Authenticate header that The response below is an example of a WWW-Authenticate header that
includes the resource identifier. includes the resource identifier.
HTTP/1.1 400 Bad Request HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_request", WWW-Authenticate: Bearer resource_metadata=
error_description="No access token was provided in this request",
resource_metadata=
"https://resource.example.com/.well-known/oauth-protected-resource" "https://resource.example.com/.well-known/oauth-protected-resource"
The HTTP status code and error string in the example response above The HTTP status code in the example response above is defined by
are defined by [RFC6750]. [RFC6750].
This parameter MAY also be used in WWW-Authenticate responses using This parameter MAY also be used in WWW-Authenticate responses using
authorization schemes other than "Bearer" [RFC6750], such as the DPoP authorization schemes other than "Bearer" [RFC6750], such as the DPoP
scheme defined by [RFC9449]. scheme defined by [RFC9449].
The resource_metadata parameter MAY be combined with other parameters The resource_metadata parameter MAY be combined with other parameters
defined in other extensions, such as the max_age parameter defined by defined in other extensions, such as the max_age parameter defined by
[RFC9470]. [RFC9470].
5.2. Changes to Resource Metadata 5.2. Changes to Resource Metadata
skipping to change at line 659 skipping to change at line 659
after validating them as described in Section 3.3. Among other after validating them as described in Section 3.3. Among other
things, this enables a resource server to change which authorization things, this enables a resource server to change which authorization
servers it uses without any other coordination with clients. servers it uses without any other coordination with clients.
5.3. Client Identifier and Client Authentication 5.3. Client Identifier and Client Authentication
The way in which the client identifier is established at the The way in which the client identifier is established at the
authorization server is out of scope for this specification. authorization server is out of scope for this specification.
This specification is intended to be deployed in scenarios where the This specification is intended to be deployed in scenarios where the
client has no prior knowledge about the resource server, and the client has no prior knowledge about the resource server and where the
resource server might or might not have prior knowledge about the resource server might or might not have prior knowledge about the
client. client.
There are some existing methods by which an unrecognized client can There are some existing methods by which an unrecognized client can
make use of an authorization server, such as using dynamic client make use of an authorization server, such as using Dynamic Client
registration [RFC7591] to register the client prior to initiating the Registration [RFC7591] to register the client prior to initiating the
authorization flow. Future OAuth extensions might define authorization flow. Future OAuth extensions might define
alternatives, such as using URLs to identify clients. alternatives, such as using URLs to identify clients.
5.4. Compatibility with Other Authentication Methods 5.4. Compatibility with Other Authentication Methods
Resource servers MAY return other WWW-Authenticate headers indicating Resource servers MAY return other WWW-Authenticate headers indicating
various authentication schemes. This allows the resource server to various authentication schemes. This allows the resource server to
support clients that may or may not implement this specification and support clients that may or may not implement this specification and
allows clients to choose their preferred authentication scheme. allows clients to choose their preferred authentication scheme.
6. String Operations 6. String Operations
Processing some OAuth 2.0 messages requires comparing values in the Processing some OAuth 2.0 messages requires comparing values in the
messages to known values. For example, the member names in the messages to known values. For example, the member names in the
metadata response might be compared to specific member names such as metadata response might be compared to specific member names such as
"resource". Comparing Unicode strings [UNICODE], however, has resource. Comparing Unicode strings [UNICODE], however, has
significant security implications. significant security implications.
Therefore, comparisons between JSON strings and other Unicode strings Therefore, comparisons between JSON strings and other Unicode strings
MUST be performed as specified below: MUST be performed as specified below:
1. Remove any JSON-applied escaping to produce an array of Unicode 1. Remove any JSON-applied escaping to produce an array of Unicode
code points. code points.
2. Unicode Normalization [USA15] MUST NOT be applied at any point to 2. Unicode Normalization [USA15] MUST NOT be applied at any point to
either the JSON string or the string it is to be compared either the JSON string or the string it is to be compared
skipping to change at line 726 skipping to change at line 726
The client SHOULD still follow OAuth best practices and request The client SHOULD still follow OAuth best practices and request
tokens with as limited a scope as possible for the given operation, tokens with as limited a scope as possible for the given operation,
as described in Section 2.3 of "Best Current Practice for OAuth 2.0 as described in Section 2.3 of "Best Current Practice for OAuth 2.0
Security" [RFC9700]. Security" [RFC9700].
7.3. Impersonation Attacks 7.3. Impersonation Attacks
TLS certificate checking MUST be performed by the client as described TLS certificate checking MUST be performed by the client as described
in [RFC9525] when making a protected resource metadata request. in [RFC9525] when making a protected resource metadata request.
Checking that the server certificate is valid for the resource Checking that the server certificate is valid for the resource
identifier URL prevents man-in-the-middle and DNS-based attacks. identifier URL prevents adversary-in-the-middle and DNS-based
These attacks could cause a client to be tricked into using an attacks. These attacks could cause a client to be tricked into using
attacker's resource server, which would enable impersonation of the an attacker's resource server, which would enable impersonation of
legitimate protected resource. If an attacker can accomplish this, the legitimate protected resource. If an attacker can accomplish
they can access the resources that the affected client has access to, this, they can access the resources that the affected client has
using the protected resource that they are impersonating. access to, using the protected resource that they are impersonating.
An attacker may also attempt to impersonate a protected resource by An attacker may also attempt to impersonate a protected resource by
publishing a metadata document that contains a resource metadata publishing a metadata document that contains a resource metadata
parameter using the resource identifier URL of the protected resource parameter using the resource identifier URL of the protected resource
being impersonated but that contains information of the attacker's being impersonated but that contains information of the attacker's
choosing. This would enable it to impersonate that protected choosing. This would enable it to impersonate that protected
resource, if accepted by the client. To prevent this, the client resource, if accepted by the client. To prevent this, the client
MUST ensure that the resource identifier URL it is using as the MUST ensure that the resource identifier URL it is using as the
prefix for the metadata request exactly matches the value of the prefix for the metadata request exactly matches the value of the
resource metadata parameter in the protected resource metadata resource metadata parameter in the protected resource metadata
skipping to change at line 792 skipping to change at line 792
another for consistency when these lists are used by the application another for consistency when these lists are used by the application
profile. profile.
Secure determination of appropriate authorization servers to use with Secure determination of appropriate authorization servers to use with
a protected resource for all use cases is out of scope for this a protected resource for all use cases is out of scope for this
specification. This specification assumes that the client has a specification. This specification assumes that the client has a
means of determining appropriate authorization servers to use with a means of determining appropriate authorization servers to use with a
protected resource and that the client is using the correct metadata protected resource and that the client is using the correct metadata
for each protected resource. Implementers need to be aware that if for each protected resource. Implementers need to be aware that if
an inappropriate authorization server is used by the client, an an inappropriate authorization server is used by the client, an
attacker may be able to act as a man-in-the-middle proxy to a valid attacker may be able to act as an adversary-in-the-middle proxy to a
authorization server without it being detected by the authorization valid authorization server without it being detected by the
server or the client. authorization server or the client.
The ways to determine the appropriate authorization servers to use The ways to determine the appropriate authorization servers to use
with a protected resource are, in general, application dependent. with a protected resource are, in general, application dependent.
For instance, some protected resources are used with a fixed For instance, some protected resources are used with a fixed
authorization server or set of authorization servers, the locations authorization server or a set of authorization servers, the locations
of which may be well known, or which could be published as metadata of which may be known via out-of-band mechanisms. Alternatively, as
values by the protected resource. In other cases, the set of described in this specification, the locations of the authorization
authorization servers that can be used with a protected resource can servers could be published by the protected resource as metadata
by dynamically changed by administrative actions or by changes to the values. In other cases, the set of authorization servers that can be
set of authorization servers adhering to a trust framework. Many used with a protected resource can be dynamically changed by
other means of determining appropriate associations between protected administrative actions or by changes to the set of authorization
resources and authorization servers are also possible. servers adhering to a trust framework. Many other means of
determining appropriate associations between protected resources and
authorization servers are also possible.
7.7. Server-Side Request Forgery (SSRF) 7.7. Server-Side Request Forgery (SSRF)
The OAuth client is expected to fetch the authorization server The OAuth client is expected to fetch the authorization server
metadata based on the value of the issuer in the resource server metadata based on the value of the issuer in the resource server
metadata. Since this specification enables clients to interoperate metadata. Since this specification enables clients to interoperate
with RSs and ASes it has no prior knowledge of, this opens a risk for with RSs and ASes it has no prior knowledge of, this opens a risk for
Server-Side Request Forgery (SSRF) attacks by malicious users or Server-Side Request Forgery (SSRF) attacks by malicious users or
malicious resource servers. Clients SHOULD take appropriate malicious resource servers. Clients SHOULD take appropriate
precautions against SSRF attacks, such as blocking requests to precautions against SSRF attacks, such as blocking requests to
skipping to change at line 838 skipping to change at line 840
by following best practices for OAuth user interfaces, such as by following best practices for OAuth user interfaces, such as
providing clear notice to the user, displaying the authorization providing clear notice to the user, displaying the authorization
server's domain name, supporting origin-bound phishing-resistant server's domain name, supporting origin-bound phishing-resistant
authenticators, supporting the use of password managers, and applying authenticators, supporting the use of password managers, and applying
heuristic checks such as domain reputation. heuristic checks such as domain reputation.
7.9. Differences Between Unsigned and Signed Metadata 7.9. Differences Between Unsigned and Signed Metadata
Unsigned metadata is integrity protected by the use of TLS at the Unsigned metadata is integrity protected by the use of TLS at the
site where it is hosted. This means that its security is dependent site where it is hosted. This means that its security is dependent
upon the Internet Public Key Infrastructure (PKI) [RFC9525]. Signed upon the Internet Public Key Infrastructure using X.509 (PKIX), as
metadata is additionally integrity protected by the JWS signature described in [RFC9525]. Signed metadata is additionally integrity
applied by the issuer, which is not dependent upon the Internet PKI. protected by the JWS signature applied by the issuer, which is not
dependent upon the Internet PKI.
When using unsigned metadata, the party issuing the metadata is the When using unsigned metadata, the party issuing the metadata is the
protected resource itself, which is represented by the resource value protected resource itself, which is represented by the resource value
in the metadata, whereas when using signed metadata, the party in the metadata, whereas when using signed metadata, the party
issuing the metadata is represented by the iss (issuer) claim in the issuing the metadata is represented by the iss (issuer) claim in the
signed metadata. When using signed metadata, applications can make signed metadata. When using signed metadata, applications can make
trust decisions based on the issuer that performed the signing -- trust decisions based on the issuer that performed the signing --
information that is not available when using unsigned metadata. How information that is not available when using unsigned metadata. How
these trust decisions are made is out of scope for this these trust decisions are made is out of scope for this
specification. specification.
7.10. Metadata Caching 7.10. Metadata Caching
Protected resource metadata is retrieved using an HTTP GET request, Protected resource metadata is retrieved using an HTTP GET request,
as specified in Section 3.1. Normal HTTP caching behaviors apply, as specified in Section 3.1. Normal HTTP caching behaviors apply,
meaning that the GET may retrieve a cached copy of the content, meaning that the GET request may retrieve a cached copy of the
rather than the latest copy. Implementations should utilize HTTP content, rather than the latest copy. Implementations should utilize
caching directives such as Cache-Control with max-age, as defined in HTTP caching directives such as Cache-Control with max-age, as
[RFC9111], to enable caching of retrieved metadata for appropriate defined in [RFC9111], to enable caching of retrieved metadata for
time periods. appropriate time periods.
8. IANA Considerations 8. IANA Considerations
The following registration procedure is used for the registry Values are registered via Specification Required [RFC8126].
established by this specification. Registration requests should be sent to <oauth-ext-review@ietf.org>
to initiate a two-week review period. However, to allow for the
Values are registered on a Specification Required basis [RFC8126] allocation of values prior to publication of the final version of a
after a two-week review period on the <oauth-ext-review@ietf.org> specification, the designated experts may approve registration once
mailing list, on the advice of one or more designated experts. they are satisfied that the specification will be completed and
However, to allow for the allocation of values prior to publication published. However, if the specification is not completed and
of the final version of a specification, the designated experts may published in a timely manner, as determined by the designated
approve registration once they are satisfied that the specification experts, the designated experts may request that IANA withdraw the
will be completed and published. However, if the specification is registration.
not completed and published in a timely manner, as determined by the
designated experts, the designated experts may request that IANA
withdraw the registration.
Registration requests sent to the mailing list for review should use Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register OAuth Protected an appropriate subject (e.g., "Request to register OAuth Protected
Resource Metadata: example"). Resource Metadata: example").
Within the review period, the designated experts will either approve Within the review period, the designated experts will either approve
or deny the registration request, communicating this decision to the or deny the registration request, communicating this decision to the
review list and IANA. Denials should include an explanation and, if review list and IANA. Denials should include an explanation and, if
applicable, suggestions as to how to make the request successful. applicable, suggestions as to how to make the request successful. If
The IANA escalation process is followed when the designated experts the designated experts are not responsive, the registration
are not responsive within 14 days. requesters should contact IANA to escalate the process.
Criteria that should be applied by the designated experts include Designated experts should apply the following criteria when reviewing
determining whether the proposed registration duplicates existing proposed registrations: They must be unique -- that is, they should
functionality, is likely to be generally applicable or useful only not duplicate existing functionality; they are likely generally
for a single application, and makes sense. applicable, as opposed to being used for a single application; and
they are clear and fit the purpose of the registry.
IANA must only accept registry updates from the designated experts IANA must only accept registry updates from the designated experts
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
In order to enable broadly informed review of registration decisions, In order to enable broadly informed review of registration decisions,
there should be multiple designated experts to represent the there should be multiple designated experts to represent the
perspectives of different applications using this specification. In perspectives of different applications using this specification. In
cases where registration may be perceived as a conflict of interest cases where registration may be perceived as a conflict of interest
for a particular expert, that expert should defer to the judgment of for a particular expert, that expert should defer to the judgment of
the other experts. the other experts.
The mailing list is used to enable public review of registration The mailing list is used to enable public review of registration
requests, which enables both designated experts and other interested requests, which enables both designated experts and other interested
parties to provide feedback on proposed registrations. The reason to parties to provide feedback on proposed registrations. Designated
allow the designated experts to allocate values prior to publication experts may allocate values prior to publication of the final
as a final specification is to enable giving authors of specification. This allows authors to receive guidance from the
specifications proposing registrations the benefit of review by the designated experts early, so any identified issues can be fixed
designated experts before the specification is completely done, so before the final specification is published.
that if problems are identified, the authors can iterate and fix them
before publication of the final specification.
8.1. OAuth Protected Resource Metadata Registry 8.1. OAuth Protected Resource Metadata Registry
This specification establishes the "OAuth Protected Resource This specification establishes the "OAuth Protected Resource
Metadata" registry for OAuth 2.0 protected resource metadata names. Metadata" registry for OAuth 2.0 protected resource metadata names.
The registry records the protected resource metadata parameter and a The registry records the protected resource metadata parameter and a
reference to the specification that defines it. reference to the specification that defines it.
8.1.1. Registration Template 8.1.1. Registration Template
skipping to change at line 1203 skipping to change at line 1202
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>. September 2023, <https://www.rfc-editor.org/info/rfc9449>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023, RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>. <https://www.rfc-editor.org/info/rfc9525>.
[UNICODE] The Unicode Consortium, "The Unicode Standard", [UNICODE] The Unicode Consortium, "The Unicode Standard",
<https://www.unicode.org/versions/latest/>. <https://www.unicode.org/versions/latest/>.
[USA15] Davis, M., Ed. and K. Whistler, Ed., "Unicode [USA15] Whistler, K., Ed., "Unicode Normalization Forms", Unicode
Normalization Forms", Unicode Standard Annex #15, 1 June Standard Annex #15, 14 August 2024,
2015, <https://www.unicode.org/reports/tr15/tr15-43.html>.
Latest version available at
<https://www.unicode.org/reports/tr15/>. <https://www.unicode.org/reports/tr15/>.
9.2. Informative References 9.2. Informative References
[FAPI.MessageSigning] [FAPI.MessageSigning]
Tonge, D. and D. Fett, "FAPI 2.0 Message Signing (Draft)", Tonge, D. and D. Fett, "FAPI 2.0 Message Signing (Draft)",
24 March 2023, 24 March 2023,
<https://openid.net/specs/fapi-2_0-message-signing.html>. <https://openid.net/specs/fapi-2_0-message-signing.html>.
[IANA.JOSE] [IANA.JOSE]
 End of changes. 25 change blocks. 
94 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.48.