jiebi/CodeConvo huggingface dataset:
Code change:
The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.

Related discussion:
text: 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
Code change:
The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.

Related discussion:
text: this specification, the same defenses against attacks that might be mounted that use this information should be applied. <del> 7.5. </del> <ins> 7.6. </ins> Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this
Code change:
The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.

Related discussion:
text: against one another for consistency when these lists are used by the application profile. <del> 7.6. </del> <ins> 7.7. </ins> The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server
Code change:
The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.

Related discussion:
text: recommendations can be found in the OWASP SSRF Prevention Cheat Sheet OWASP.SSRF. <del> 7.7. </del> <ins> 7.8. </ins> This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL.  If this resource
Code change:
From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.

Related discussion:
text: 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",
Code change:
From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.

Related discussion:
text: 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"
Code change:
From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.

Related discussion:
text: 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
Code change:
From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.

Related discussion:
text: this specification, the same defenses against attacks that might be mounted that use this information should be applied. <del> 7.5. </del> <ins> 7.6. </ins> Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this
Code change:
From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.

Related discussion:
text: against one another for consistency when these lists are used by the application profile. <del> 7.6. </del> <ins> 7.7. </ins> The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server
Code change:
From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.

Related discussion:
text: recommendations can be found in the OWASP SSRF Prevention Cheat Sheet OWASP.SSRF. <del> 7.7. </del> <ins> 7.8. </ins> This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL.  If this resource
Code change:
As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.

Related discussion:
text: 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.
Code change:
As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.

Related discussion:
text: 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
Code change:
As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.

Related discussion:
text: 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-
Code change:
As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.

Related discussion:
text: 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.
Code change:
As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.

Related discussion:
text: 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:
Code change:
As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.

Related discussion:
text: 3.3. The "resource" value returned MUST be identical to the protected <del> resource's resource identifier value that was concatenated with the well-known URI path suffix to create the URL used to retrieve the </del> <ins> resource's resource identifier value into which the well-known URI path suffix was inserted to create the URL used to retrieve the </ins> metadata.  If these values are not identical, the data contained in the response MUST NOT be used.
Code change:
Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.

Related discussion:
text: 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
Code change:
Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.

Related discussion:
text: 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