jiebi/CodeConvo huggingface dataset:
2.3. This specification does not define authorization server discovery.  A <del> client MAY contact the resource and leverage the WWW-Authentication response (see section 3 of RFC6750), maintain a static mapping or use other means to identify the authorization server. </del> <ins> client MAY contact the resource server and leverage the WWW- Authentication response (see section 3 of RFC6750), maintain a static mapping or use other means to identify the authorization server. </ins> 2.4. The client performs token exchange as defined in RFC8693 with the <del> authorization server for its own domain (e.g.  Domain A), in order to </del> <ins> authorization server for its own domain (e.g., Domain A) in order to </ins> obtain an authorization grant that can be used with the authorization <del> server of a different domain (e.g.  Domain B) as specified in section </del> <ins> server of a different domain (e.g., Domain B) as specified in section </ins> 1.3 of RFC6749. 2.4.1.
between the authorization servers.  To achieve a maintainable and flexible systems clients SHOULD NOT request a specific "requested_token_type" during the token exchange and SHOULD NOT <del> require a certain format or parse the authorization grant (for instance in caes of JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. </del> <ins> require a certain format or parse the authorization grant (e.g., if the token is encoded as a JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. </ins> Authorization servers MAY use an existing grant type such us "urn:ietf:params:oauth:grant-type:jwt-bearer" to indicate a JWT or
2.4.4. All of section 2.2 of RFC8693 applies.  In addition, the following <del> applies to specification that conform to this specification. </del> <ins> applies to implementations that conform to this specification. </ins> <del> Returned authorization grant MUST be audienced to the requested </del> <ins> Returned authorization grants MUST be audienced to the requested </ins> authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients <del> from presenting their access tokens as an authorization grant to an authorization server in a different domain. </del> <ins> from presenting access tokens as an authorization grant to an authorization server in a different domain. </ins> The returned authorization grant MAY be audienced to multiple authorization servers, provided that trust relationships exist with them (e.g. through federation).  It is RECOMMENDED that only one audience is used to prevent an authorization server in one <del> domain from presenting the client's authorization grant to another authorization in another trust domain.  For example, this will prevent the authorization server in Domain B from presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. </del> <ins> domain from presenting the client's authorization grant to an authorization server in a different trust domain.  For example, this will prevent the authorization server in Domain B from presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. </ins> 2.4.5.
2.6. Authorization servers MAY transcribe claims when either producing <del> authorization grant at the token exchange flow or access tokens at </del> <ins> authorization grants in the token exchange flow or access tokens in </ins> the assertion flow. : Subject identifier can differ between the parties involved.  For instance: A user is known at domain A by "johndoe@a.org" but in <del> domain B by "doe.john".  The mapping from one identifier to the other MAY either happen in the token exchange step and updated identifer is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </del> <ins> domain B by "doe.john@b.org".  The mapping from one identifier to the other MAY either happen in the token exchange step and the updated identifer is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </ins>
authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. <del> A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange.  The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. </del> 2.1.
The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in <del> domain A (https://a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://b.org/auth). </del> <ins> domain A (https://as.a.org/auth) to receive an authorization grant for the authorization server in trust domain B (https://as.b.org/ auth). </ins> 2.5.
If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" as defined in <del> RFC7521.  Otherwise, the client SHOULD request an access token using </del> <ins> RFC7523.  Otherwise, the client SHOULD request an access token using </ins> the "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" as defined in RFC7521 (Section 4.1).  For the purpose of this specification the following descriptions apply:
2.5.2. <del> All of RFC7521 (Section 5.2 in specific) applies, along with the following processing rules: </del> <ins> All of Section 5.2 RFC7521 applies, in addition to the following processing rules: </ins> <del> The request MUST be denied if the presented authorization grant does not include an "aud" claim identifying the authorization server that processes the request. </del> <ins> The "aud" claim MUST identify the Authorization Server as a valid intended audience of the assertion using either the token endpoint as described Section 3 RFC7523 or the issuer identifier as defined in Section 2 of RFC8414. </ins> The authorization server SHOULD deny the request if it is not able to identify the subject.
Preserving this information is referred to as identity chaining. This document defines a mechanism for preserving identity chaining information across trust domains using a combination of OAuth 2.0 <del> Token Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521. </del> <ins> Token Exchange RFC8693 and JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC7523. </ins> 1.1.
2. This specification describes a combination of OAuth 2.0 Token <del> Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521 to achieve identity chaining across trust domains. </del> <ins> Exchange RFC8693 and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC7523 to achieve identity chaining across trust domains. </ins> A client in trust domain A that needs to access a resource server in trust domain B requests an authorization grant from the authorization
2.2. The Identity Chaining flow outlined below describes how a combination <del> of OAuth 2.0 Token Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521 are used to address the use cases identified.  The appendix include two </del> <ins> of OAuth 2.0 Token Exchange RFC8693 and JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC7523 are used to address the use cases identified.  The appendix include two </ins> additional examples that describe how this flow is used.  In one example, the resource server acts as the client and in the other, the authorization server acts as the client.
2.4.3. <del> The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and flexible systems clients SHOULD NOT request a specific "requested_token_type" during the token exchange and SHOULD NOT require a certain format or parse the authorization grant (e.g., if the token is encoded as a JWT).  The "issued_token_type" parameter in the response indicates the type and SHOULD be passed into the assertion request.  This allows flexibility for authorization servers to change format and content. Authorization servers MAY use an existing grant type such us "urn:ietf:params:oauth:grant-type:jwt-bearer" to indicate a JWT or "urn:ietf:params:oauth:grant-type:saml2-bearer" to indicate SAML. Other grant types MAY be used to indicate other formats. 2.4.4. </del> All of section 2.2 of RFC8693 applies.  In addition, the following applies to implementations that conform to this specification.
2.5. <del> The client presents the authorization grant it received from the authorization server in its own domain and presents it to the authorization server in the domain of the resources server it wants to access as defined in the "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" RFC7521. </del> <ins> The client presents the token it received from the authorization server in its own domain as an authorization grant to the authorization server in the domain of the resource server it wants to access as defined in RFC7523. </ins> 2.5.1. <del> If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" as defined in RFC7523.  Otherwise, the client SHOULD request an access token using the "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" as defined in RFC7521 (Section 4.1).  For the </del> <ins> The authorization grant is a JWT bearer token, which the client uses to request an access token as described in the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC7523.  For the </ins> purpose of this specification the following descriptions apply: The client MAY indicate the audience it is trying to access through
2.5.2. <del> All of Section 5.2 RFC7521 applies, in addition to the following processing rules: </del> <ins> The authorization server MUST validate the JWT authorization grant as specified in Sections 3 and 3.1 of RFC7523.  The following processing rules also apply: </ins> The "aud" claim MUST identify the Authorization Server as a valid intended audience of the assertion using either the token endpoint
instance: A user is known at domain A by "johndoe@a.org" but in domain B by "doe.john@b.org".  The mapping from one identifier to the other MAY either happen in the token exchange step and the <del> updated identifer is reflected in returned authorization grant or </del> <ins> updated identifier is reflected in returned authorization grant or </ins> in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above.
trust domains. A client in trust domain A that needs to access a resource server in <del> trust domain B requests an authorization grant from the authorization server for trust domain A via a token exchange.  The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. </del> <ins> trust domain B requests a JWT authorization grant from the authorization server for trust domain A via a token exchange.  The client in trust domain A presents the received grant as an assertion to the authorization server in domain B in order to obtain an access token for the protected resource in domain B.  The client in domain A may be a resource server, or it may be the authorization server itself. </ins> 2.1.
server of Domain B.  See authorization-server-discovery. (B) The client exchanges its token at the authorization server of <del> its own domain (Domain A) for an authorization grant that can be used at the authorization server in Domain B.  See token-exchange. </del> <ins> its own domain (Domain A) for a JWT authorization grant that can be used at the authorization server in Domain B.  See token- exchange. </ins> (C) The authorization server of Domain A processes the request and <del> returns an authorization grant that the client can use with the </del> <ins> returns a JWT authorization grant that the client can use with the </ins> authorization server of Domain B.  This requires a trust relationship between Domain A and Domain B (e.g., through federation).
The client performs token exchange as defined in RFC8693 with the authorization server for its own domain (e.g., Domain A) in order to <del> obtain an authorization grant that can be used with the authorization server of a different domain (e.g., Domain B) as specified in section 1.3 of RFC6749. </del> <ins> obtain a JWT authorization grant that can be used with the authorization server of a different domain (e.g., Domain B) as specified in section 1.3 of RFC6749. </ins> 2.4.1.
All of section 2.2 of RFC8693 applies.  In addition, the following applies to implementations that conform to this specification. <del> The "aud" claim in the returned authorization grant MUST identify the requested authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients from presenting access tokens as an authorization grant to an authorization server in a different domain. </del> <ins> The "aud" claim in the returned JWT authorization grant MUST identify the requested authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients from presenting access tokens as an authorization grant to an authorization server in a different domain. </ins> <del> The "aud" claim included in the returned authorization grant MAY identify multiple authorization servers, provided that trust </del> <ins> The "aud" claim included in the returned JWT authorization grant MAY identify multiple authorization servers, provided that trust </ins> relationships exist with them (e.g. through federation).  It is RECOMMENDED that the "aud" claim is restricted to a single authorization server to prevent an authorization server in one
The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in <del> domain A (https://as.a.org/auth) to receive an authorization grant </del> <ins> domain A (https://as.a.org/auth) to receive a JWT authorization grant </ins> for the authorization server in trust domain B (https://as.b.org/ auth). 2.5. <del> The client presents the token it received from the authorization server in its own domain as an authorization grant to the authorization server in the domain of the resource server it wants to access as defined in RFC7523. </del> <ins> The client presents the JWT authorization grant it received from the authorization server in its own domain as an authorization grant to the authorization server in the domain of the resource server it wants to access as defined in RFC7523. </ins> 2.5.1.
instance: A user is known at domain A by "johndoe@a.org" but in domain B by "doe.john@b.org".  The mapping from one identifier to the other MAY either happen in the token exchange step and the <del> updated identifier is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </del> <ins> updated identifier is reflected in returned JWT authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </ins>
: The authorization server performing the assertion flow MAY <del> leverage claims from the presented authorization grant and include them in the returned access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </del> <ins> leverage claims from the presented JWT authorization grant and include them in the returned access token.  The populated claims SHOULD be namespaced or validated to prevent the injection of invalid claims. </ins> The representation of transcribed claims and their format is not defined in this specification.
JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public <del> and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model.  Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </del> <ins> and private claims.  This specification aims to express metadata of the properties of the Verifiable Credentials utilizing registered JWT claims, while allowing Issuers to use other registered, public, or private claims to make statements about the Subject of the Verifiable Credential. </ins> 1.3.
referenced in the credential.  This process is further described in I-D.ietf-oauth-selective-disclosure-jwt. <del> To support revocation of Verifiable Credentials, an optional fourth party can be involved, a Status Provider, who delivers revocation information to Verifiers.  (The Verifier can also serve as the Status Provider.) </del> <ins> To support revocation of Verifiable Credentials, revocation information can optionally be retrieved from a Status Provider.  The role of a Status Provider can be fulfilled by either a fourth party or by the Issuer. </ins> This specification defines Verifiable Credentials based on the SD-JWT format with a JWT Claim Set.
SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC) <del> draft-terbu-sd-jwt-vc-latest </del> <ins> draft-terbu-oauth-sd-jwt-vc-latest </ins> Abstract This specification describes data formats as well as validation and <del> processing rules to express Verifiable Credentials with JSON payload based on the SD-JWT format I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth- selective-disclosure-jwt format.  It can be used when there are no selective disclosable claims, too. </ins> 1.
Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. <del> SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I- D.ietf-oauth-selective-disclosure-jwt. </del> <ins> When there are selectively disclosable claims, SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I-D.ietf-oauth- selective-disclosure-jwt. </ins> 4.2.1.
Additional public claims MAY be used in SD-JWT VCs depending on the application. <ins> 4.2.2.4. An SD-JWT VC MAY have no selectively disclosable claims.  In that case, the SD-JWT VC MUST NOT contain the claim in the JWT body.  It also MUST NOT have any Disclosures. </ins> 4.3. The following is a non-normative example of an unsecured payload of
Abstract This specification describes data formats as well as validation and <del> processing rules to express Verifiable Credentials with JSON payload based on the SD-JWT format I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> processing rules to express Verifiable Credentials with JSON payloads based on the Selective Disclosure for JWTs (SD-JWT) I-D.ietf-oauth- selective-disclosure-jwt format.  It can be used when there are no selective disclosable claims, too. </ins> 1.
Provider.) This specification defines Verifiable Credentials based on the SD-JWT <del> format with a JWT Claim Set. </del> <ins> format with a JWT Claim Set. It can be used when there are no selective disclosable claims, too. </ins> 1.2. JSON Web Tokens (JWTs) RFC7519 can in principle be used to express Verifiable Credentials in a way that is easy to understand and <del> process as it builds upon established web primitives.  While JWT- based credentials enable selective disclosure, i.e., the ability for a Holder to disclose only a subset of the contained claims, in an Identity Provider ecosystem by issuing new JWTs to the Verifier for every presentation, this approach does not work in the three-party- model. </del> <ins> process as it builds upon established web primitives. </ins> Selective Disclosure JWT (SD-JWT) I-D.ietf-oauth-selective- disclosure-jwt is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by <del> the Issuer).  This format is therefore perfectly suited for Verifiable Credentials. SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how Verifiable Credentials can be expressed using SD-JWT. JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model.  Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </del> <ins> the Issuer). SD-JWT is a superset of JWT as it can also be used when there are no selectively disclosable claims and also supports JWS JSON serialization, which is useful for long term archiving and multi signatures.  However, SD-JWT itself does not define the claims that must be used within the payload or their semantics. This specification therefore uses SD-JWT and the well-established JWT content rules and extensibility model as basis for representing Verifiable Credentials with JSON payload.  Those Verifiable Credentials are called SD-JWT VCs. SD-JWTs VC can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public and private claims. </ins> 1.3.
1.1. <del> In the so-called Three-Party-Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are </del> <ins> In the so-called Issuer-Holder-Verifier Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are </ins> cryptographically signed statements about a Subject, typically the Holder.