jiebi/CodeConvo huggingface dataset:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 4.1.2. </del> <ins> 4.3. </ins> <del> The following rules apply to validating the Client Attestation JWT. Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating the Client Attestation PoP JWT.  Application of additional restrictions and policy are at the </ins> discretion of the Authorization Server. The JWT MUST contain an "iss" (issuer) claim with a value
reason, then it MUST request a new Client Attestation JWT from its Client Backend. <del> 6. </del> <ins> 7. </ins> <del> 6.1. </del> <ins> 7.1. </ins> Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of <del> the end user using the client instance through claim values </del> <ins> the end user using the Client Instance through claim values </ins> (including the public key in the "cnf" claim).  Client deployments are therefore RECOMMENDED to use different client attestations across different authorization servers. <del> 7. </del> <ins> 8. </ins> The guidance provided by RFC7519 and RFC8725 applies. <del> 7.1. </del> <ins> 8.1. </ins> The following mechanisms exist within this client authentication method in order to allow an authorization server to detect replay
implementation requirements.  The "jti" method is mandatory and hence acts as a default fallback. <del> 8. 8.1. This section registers the value "client-assertion-type:jwt-client- attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- attestation Common Name: OAuth 2.0 Attested Key-Based Client Authentication Change Controller: IESG Specification Document: TBC </del> <ins> 9. </ins> <del> 8.2. </del> <ins> 9.1. </ins> This section registers the value "attest_jwt_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by
7.2. <ins> The "scopes_supported" parameter is the list of scopes the resource server is willing to disclose that it supports.  It is not meant to indicate that an OAuth client should request all scopes in the list. The client SHOULD still follow OAuth best practices and request tokens with as limited scope as possible for the given operation, as described in Section 2.3 of OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics. 7.3. </ins> TLS certificate checking MUST be performed by the client, as described in TLSRequirements, when making a protected resource metadata request.  Checking that the server certificate is valid for
7.4. <ins> If a client expects to interact with multiple resource servers, the client SHOULD request audience-restricted access tokens using RFC8707, and the authorization server SHOULD support audience- restricted access tokens. Without audience-restricted access tokens, a malicious resource server (RS1) may be able to use the "WWW-Authenticate" header to get a client to request an access token with a scope used by a legitimate resource server (RS2), and after the client sends a request to RS1, then RS1 could re-use the access token at RS2. While this attack is not explicitly enabled by this specification, and is possible in a plain OAuth 2.0 deployment, it is made somewhat more likely by the use of dynamically-configured clients.  As such, the use of audience-restricted access tokens and Resource Indicators RFC8707 is RECOMMENDED when using the features in this specification. 7.5. </ins> Publishing information about the protected resource in a standard format makes it easier for both legitimate clients and attackers to use the protected resource.  Whether a protected resource publishes
RFC7033, in a manner related to the description in Section 2 of OpenID.Discovery. <ins> PRMetadata defines metadata values that a protected resource can publish, which includes things like which scopes are supported, how a client can present an access token, and more.  These values may be used by other specifications, such as the "jwks_uri" used to publish public keys the resource server uses to sign resource responses, as described in Section 5.6.2 of FAPI.MessageSigning. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
OPTIONAL.  URL of the protected resource's JWK Set JWK document. <del> This contains keys belonging to the protected resource.  For instance, this JWK Set MAY contain encryption key(s) that are used to encrypt access tokens to the protected resource.  When both signing and encryption keys are made available, a "use" (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage. </del> <ins> This contains public keys belonging to the protected resource. For instance, this JWK Set MAY contain encryption key(s) that are used to encrypt access tokens to the protected resource.  The JWK Set MAY also contain signing key(s) that the resource server uses to sign responses.  When both signing and encryption keys are made available, a "use" (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage. </ins> RECOMMENDED.  JSON array containing a list of the RFC6749 "scope"
This specification defines the following term: <del> A URL that uses the "https" scheme and has no fragment components where ".well-known" RFC5785 resources containing information about the protected resource are published. </del> <ins> The Protected resource's resource identifier, which is a URL that uses the "https" scheme and has no query or fragment components. Protected resource metadata is published at a ".well-known" location RFC5785 derived from this resource identifier, as described in PRConfig. </ins> 2.
REQUIRED.  The protected resource's resource identifier, which is <del> a URL that uses the "https" scheme and has no fragment components. This is the location where ".well-known" RFC5785 resources containing information about the protected resource are published. Using these well-known resources is described in PRConfig. </del> <ins> a URL that uses the "https" scheme and has no query or fragment components.  Using these well-known resources is described in PRConfig. </ins> OPTIONAL.  JSON array containing a list of OAuth authorization
Protected resources supporting metadata MUST make a JSON document containing metadata as specified in PRMetadata available at a path <del> formed by concatenating a well-known URI string such as "/.well- known/oauth-protected-resource" to the protected resource's resource identifier.  The syntax and semantics of ".well-known" are defined in RFC5785.  The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry IANA.well-known. </del> <ins> formed by inserting a well-known URI string into the protected resource's resource identifier between the host component and the path component, if any.  By default, the well-known URI string used is "/.well-known/oauth-protected-resource".  The syntax and semantics of ".well-known" are defined in RFC5785.  The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry IANA.well-known. </ins> Different applications utilizing OAuth protected resources in application-specific ways may define and register different well-
as used by those applications.  For instance, if the Example application uses an OAuth protected resource in an Example-specific way, and there are Example-specific metadata values that it needs to <del> publish, then it might register and use the "example-resource- configuration" URI path suffix and publish the metadata document at the path formed by concatenating "/.well-known/example-resource- configuration" to the protected resource's resource identifier. </del> <ins> publish, then it might register and use the "example-protected- resource" URI path suffix and publish the metadata document at the path formed by inserting "/.well-known/example-protected-resource" between the host and path components of the protected resource's resource identifier.  Alternatively, many such applications will use the default well-known URI string "/.well-known/oauth-protected- resource", which is the right choice for general-purpose OAuth protected resources, and not register an application-specific one. </ins> An OAuth 2.0 application using this specification MUST specify what well-known URI string it will use for this purpose.  The same protected resource MAY choose to publish its metadata at multiple <del> well-known locations relative to its resource identifier, for example, publishing metadata at both "/.well-known/example-resource- configuration" and "/.well-known/oauth-protected-resource". </del> <ins> well-known locations derived from its resource identifier, for example, publishing metadata at both "/.well-known/example-protected- resource" and "/.well-known/oauth-protected-resource". </ins> 3.1.
component: If the resource identifier value contains a path component, any <del> terminating "/" MUST be removed before appending "/.well-known/" and the well-known URI path suffix.  The consumer of the metadata would make the following request when the resource identifier is </del> <ins> terminating "/" MUST be removed before inserting "/.well-known/" and the well-known URI path suffix between the host component and the path component.  The consumer of the metadata would make the following request when the resource identifier is </ins> "https://resource.example.com/resource1" and the well-known URI path suffix is "oauth-protected-resource" to obtain the metadata, since the resource identifier contains a path component:
metadata.  If these values are not identical, the data contained in the response MUST NOT be used. <ins> If the protected resource metadata was retrieved from a URL returned by the protected resource via the WWW-Authenticate "resource_metadata" parameter, then the "resource" value returned MUST be identical to the URL that the client used to make the request to the resource server.  If these values are not identical, the data contained in the response MUST NOT be used. </ins> 4. To support use cases in which the set of legitimate protected
5. A protected resource MAY use a "WWW-Authenticate" response to return <del> its resource identifier to the client.  The client can then retrieve protected resource metadata using the resource identifier as described in PRConfig.  The client might then, for instance, determine what authorization server to use for the resource based on protected resource metadata retrieved. </del> <ins> a URL to its protected resource metadata to the client.  The client can then retrieve protected resource metadata as described in PRConfig.  The client might then, for instance, determine what authorization server to use for the resource based on protected resource metadata retrieved. </ins> 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
presenting an access token. The resource server responds with a "WWW-Authenticate" header <del> including the resource identifier of the protected resource. </del> <ins> including the URL of the protected resource metadata. </ins> <del> The client fetches resource metadata from the ".well-known/oauth- protected-resource" location derived from the resource identifier according to PRConfig. </del> <ins> The client fetches the protected resource metadata from this URL. </ins> The protected resource responds with the protected resource metadata according to PRConfigurationResponse. <ins> The client validates the protected resource metadata. </ins> The client builds the authorization server metadata URL from an issuer identifier in the resource metadata according to RFC8414 and makes a request to fetch the authorization server metadata.
5.1. This specification introduces a new parameter in the "WWW- <del> Authenticate" response to indicate the resource identifier of the protected resource: </del> <ins> Authenticate" response to indicate the protected resource metadata URL: </ins> <del> The resource identifier of the protected resource. </del> <ins> The URL of the protected resource metadata. </ins> The HTTP status code and error string in the response are defined by RFC6750. <del> The issuer parameter MAY be combined with other parameters defined in other extensions, such as the "max_age" parameter defined by RFC9470. </del> <ins> The "resource_metadata" parameter MAY be combined with other parameters defined in other extensions, such as the "max_age" parameter defined by RFC9470. </ins> 5.2. At any point, for any reason determined by the protected resource, the protected resource MAY respond with a new "WWW-Authenticate" <del> challenge that includes a value for the resource identifier to indicate that its metadata MAY have changed.  If the client receives such a "WWW-Authenticate" response, it is expected retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </del> <ins> challenge that includes a value for the protected resource metadata URL to indicate that its metadata MAY have changed.  If the client receives such a "WWW-Authenticate" response, it is expected retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </ins> 5.3.
OPTIONAL.  JSON array containing a list of the OAuth 2.0 Bearer Token RFC6750 presentation methods that this protected resource <del> supports.  Defined values are "["header", "fragment", "query"]", </del> <ins> supports.  Defined values are "["header", "body", "query"]", </ins> corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.
used. <del> OPTIONAL.  JSON array containing a list of the OAuth 2.0 Bearer Token RFC6750 presentation methods that this protected resource supports.  Defined values are "["header", "body", "query"]", </del> <ins> OPTIONAL.  JSON array containing a list of the supported methods of sending an OAuth 2.0 Bearer Token RFC6750 to the protected resource.  Defined values are "["header", "body", "query"]", </ins> corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.
is "/.well-known/oauth-protected-resource".  The syntax and semantics of ".well-known" are defined in RFC5785.  The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry <del> IANA.well-known. </del> <ins> IANA.well-known.  Examples of this construction can be found in PRConfigurationRequest. </ins> Different applications utilizing OAuth protected resources in application-specific ways MAY define and register different well-
the protected resource MAY respond with a new "WWW-Authenticate" challenge that includes a value for the protected resource metadata URL to indicate that its metadata MAY have changed.  If the client <del> receives such a "WWW-Authenticate" response, the client SHOULD retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </del> <ins> receives such a "WWW-Authenticate" response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </ins> 5.3.
7.6. <ins> To support use cases in which the set of legitimate authorization servers to use with the protected resource is fixed and enumerable, this specification defines the "authorization_servers" metadata value, which enables explicitly listing them.  Note that if the set of legitimate protected resources to use with an authorization server is also fixed and enumerable, lists in the protected resource metadata and authorization server metadata should be cross-checked against one another for consistency when these lists are used by the application profile. </ins> Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this specification.  This specification assumes that the client has a
other means of determining appropriate associations between protected resources and authorization servers are also possible. <del> To support use cases in which the set of legitimate authorization servers to use with the protected resource is fixed and enumerable, this specification defines the "authorization_servers" metadata value, which enables explicitly listing them.  Note that if the set of legitimate protected resources to use with an authorization server is also fixed and enumerable, lists in the protected resource metadata and authorization server metadata should be cross-checked against one another for consistency when these lists are used by the application profile. </del> 7.7. The OAuth client is expected to fetch the authorization server
IANA.well-known.  Examples of this construction can be found in PRConfigurationRequest. <ins> The term "application", as used below (and as used in RFC8414), encompasses all the components used to accomplish the task for the use case.  That can include OAuth clients, authorization servers, protected resources, and non-OAuth components, inclusive of the code running in each of them.  Applications are built to solve particular problems and may utilize many components and services. </ins> Different applications utilizing OAuth protected resources in application-specific ways MAY define and register different well- known URI path suffixes for publishing protected resource metadata
specification, and allows clients to choose their preferred authentication scheme. <del> A fair question is whether allowing clients to choose from among supported authentication methods represents an opportunity for a downgrade attack.  Since resource servers will only enumerate authentication methods acceptable to them, by definition, any choice made by the client from among them is one that the resource server is OK with.  Thus, the resource server allowing the use of different supported authentication methods does not represent an opportunity for a downgrade attack. </del> 6. Processing some OAuth 2.0 messages requires comparing values in the
RFC8414, which enables a client to obtain metadata about an OAuth 2.0 authorization server. <ins> The means by which the client obtains the location of the protected resource is out of scope of this document.  In some cases, the location may be manually configured into the client; for example, an email client could provide an interface for a user to enter the URL of their RFC8620 server.  In other cases, it may be dynamically discovered; for example, a user could enter their email address into an email client, the client could perform RFC7033 discovery (in a manner related to the description in Section 2 of OpenID.Discovery) to find the resource server, then fetch the resource server metadata to find the authorization server to use to obtain authorization to access the user's email. </ins> The metadata for a protected resource is retrieved from a well-known location as a JSON RFC8259 document, which declares information about its capabilities and optionally, its relationships to other services.
authoritative for the protected resource, as described in Impersonation. <del> The means by which the client obtains the location of the protected resource is out of scope.  In some cases, the location may be manually configured into the client.  In other cases, it may be dynamically discovered, for instance, through the use of RFC7033, in a manner related to the description in Section 2 of OpenID.Discovery. </del> PRMetadata defines metadata values that a protected resource can publish, which includes things like which scopes are supported, how a client can present an access token, and more.  These values may be
At any point, for any reason determined by the resource server, the protected resource MAY respond with a new "WWW-Authenticate" challenge that includes a value for the protected resource metadata <del> URL to indicate that its metadata MAY have changed.  If the client </del> <ins> URL to indicate that its metadata may have changed.  If the client </ins> receives such a "WWW-Authenticate" response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained, after validating them as described in
Values are registered on a Specification Required RFC8126 basis after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to <del> allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published. </del> <ins> allow for the allocation of values prior to publication of the final version of a specification, the Designated Experts may approve registration once they are satisfied that the specification will be completed and published.  However, if the specification is not completed and published in a timely manner, as determined by the Designated Experts, the Designated Experts may request that IANA withdraw the registration. </ins> Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Protected
Expert, that Expert should defer to the judgment of the other Experts. <ins> The reason for the use of the mailing list is to enable public review of registration requests, enabling both Designated Experts and other interested parties to provide feedback on proposed registrations. The reason to allow the Designated Experts to allocate values prior to publication as a final specification is to enable giving authors of specifications proposing registrations the benefit of review by the Designated Experts before the specification is completely done, so that if problems are identified, the authors can iterate and fix them before publication of the final specification. </ins> 8.1. This specification establishes the IANA "OAuth Protected Resource
("7").  All bits of the byte array at a particular index are set to a status value. <del> The complete byte array is compressed using the "DEFLATE" RFC1951 compression method and stored using the "ZLIB" RFC1950 data format.  Implementations are RECOMMENDED to use the highest compression level available. </del> <ins> The byte array is compressed using DEFLATE RFC1951 with the ZLIB RFC1950 data format.  Implementations are RECOMMENDED to use the highest compression level available. </ins> The following example illustrates a Status List that represents the statuses of 16 Referenced Tokens, requiring 16 bits (2 bytes) for the
The following content applies to the JWT Claims Set: <del> "iss": REQUIRED.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Status List Token.  In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within the Referenced Token. </del> <ins> "iss": REQUIRED when also present in the Referenced Token.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Status List Token.  In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within the Referenced Token. </ins> "sub": REQUIRED.  The "sub" (subject) claim MUST specify a unique string identifier for that Status List Token.  The value MUST be