jiebi/CodeConvo huggingface dataset:
Change:
Changes field to , adds to DPoP definition for parity with other JOSE signature methods.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit fc15fc873432dae90bce38706aa85313d831d419 https://deploy-preview-195--gnap-core-protocol-editors-URL
The signature methods all need to cover the access token, but the DPoP method currently does not. We can add the method used in the and methods.
The FAPI WG is proposing a similar DPoP profile: URL This uses the field instead of , and we could align with that.
Convergence would be helpful, do we know the status of the document?
Is this something that can be standardized in , even as a best practice or recommendation? Trying to align with all documents out there is not a long time strategy...
I've reached out to the OAuth WG on the topic of defining the field in DPoP itself. If that happens we can remove this field from our spec, but until that happens then it makes sense to keep FAPI and GNAP aligned, for now.
Regarding alignment between FAPI and GNAP... DPoP describes "htu" as while GNAP as which obviously isn't the same.

Discussion:
A timestamp of the request in integer seconds <del> When to bind a request to an access token, the access token hash </del> <ins> When a request is bound to an access token, the access token hash </ins> value.  Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the "access_token" value, where the hash algorithm used is the hash

This method is indicated by "dpop" in the "proof" field.  The client instance creates a Demonstration of Proof-of-Possession signature <del> header as described in I-D.ietf-oauth-dpop section 2.  In addition to the required fields, the DPoP body MUST also contain a digest of the request body: </del> <ins> header as described in I-D.ietf-oauth-dpop section 2.  In addition, this specification defines the following fields to be added to the DPoP payload: </ins> Digest of the request body as the value of the Digest header <del> defined in RFC3230. </del> <ins> defined in RFC3230.  When a request contains a message body, such as a POST or PUT request, this field is REQUIRED. When a request is bound to an access token, the access token hash value.  Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the "access_token" value, where the hash algorithm used is the hash algorithm used in the "alg" header parameter of the JWS's JOSE Header.  For instance, if the "alg" is "RS256", hash the "access_token" value with SHA-256, then take the left-most 128 bits and base64url encode them. </ins> 7.3.5.
Change:
Minor typos
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit b2ce64bfa924bc30b24ea9301223156ec0eb8520 https://deploy-preview-204--gnap-core-protocol-editors-URL
within (and likely other sections), the property names are plural, but the text sometimes refers to the singular property names. This should be cleaned up to be consistent one way or another.

Discussion:
described in response-token-single. When neither an access token nor key proof are used, this is an <del> unsecured request.  This type of used only for calls to the RS during a discovery phase as described in rs-request-without-token. </del> <ins> unsecured request.  This type of request is used only for calls to the RS during a discovery phase as described in rs-request- without-token. </ins> 7.1.

general-purpose APIs use a URI for this field to avoid collisions between multiple API types protected by a single AS. <del> While it is expected that many APIs will have its own properties, a </del> <ins> While it is expected that many APIs will have their own properties, a </ins> set of common properties are defined here.  Specific API implementations SHOULD NOT re-use these fields with different semantics or syntax.  The available values for these properties are

The access requested for a given object when using these fields is the cross-product of all fields of the object.  That is to say, the object represents a request for all "action" values listed within the <del> object to be used at all "locations" values listed within the object </del> <ins> object to be used at all "location" values listed within the object </ins> for all "datatype" values listed within the object.  Assuming the request above was granted, the client instance could assume that it would be able to do a "read" action against the "images" on the first
Change:
These changes replace with replace with replace with in Detached JWS and Attached JWS sections.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit df67d81f6aadce526a2eecb1d9185d684f17242c https://deploy-preview-207--gnap-core-protocol-editors-URL
I think the proposal in could have some impact on this language, as well as making sure both attached and detached JWS methods are fully aligned.
could definitely have some impact. Although, these changes touch only the used terminology.
Accept to align with JOSE terminology, will probably be updated again when crypto methods get updated.

Discussion:
7.3.1. This method is indicated by "jwsd" in the "proof" field.  A JWS <del> RFC7515 signature object is created as follows: </del> <ins> RFC7515 object is created as follows: </ins> <del> The header of the JWS MUST contain the "kid" field of the key bound to this client instance for this request.  The JWS header MUST contain an "alg" field appropriate for the key identified by kid and MUST NOT be "none".  The "b64" field MUST be set to "false" and the "crit" field MUST contain at least "b64" as specified in </del> <ins> The JOSE (JSON Object Signing and Encryption) header MUST contain the "kid" parameter of the key bound to this client instance for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by kid and MUST NOT be "none".  The "b64" parameter MUST be set to "false" and the "crit" parameter MUST contain at least "b64" as specified in RFC7797. </ins> <del> To protect the request, the JWS header MUST contain the following additional fields. </del> <ins> To protect the request, the JOSE header MUST contain the following additional parameters. </ins> The HTTP Method used to make this request, as an uppercase ASCII string.

7.3.2. This method is indicated by "jws" in the "proof" field.  A JWS <del> RFC7515 signature object is created as follows: </del> <ins> RFC7515 object is created as follows: </ins> <del> The header of the JWS MUST contain the "kid" field of the key bound to this client instance for this request.  The JWS header MUST contain an "alg" field appropriate for the key identified by "kid" and MUST NOT be "none". </del> <ins> The JOSE header MUST contain the "kid" parameter of the key bound to this client instance for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by kid and MUST NOT be "none". </ins> To protect the request, the JWS header MUST contain the following <del> additional fields. </del> <ins> additional parameters. </ins> The HTTP Method used to make this request, as an uppercase ASCII string.
Change:
…alue should be the boolean false. Please, correct me if I wrong.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 23bd329e9c764cedfe6a8dd1e26b557aa8fda9a6 https://deploy-preview-209--gnap-core-protocol-editors-URL
Ok, I will take care of it a bit later. I also suggest omitting from other examples as it's a default value.
Done.
We'll need to add an example of in at least one location, but otherwise these changes are good.
Done in URL
The intent was to make the examples bound tokens by default, so instead of changing the examples, any text surrounding these examples referring them as bearer needs to be adjusted appropriately.

Discussion:
corresponding to the token labels chosen by the client instance in the request-token-multiple. <del> In this non-normative example, two bearer tokens are issued under the names "token1" and "token2", and only the first token has a management URL associated with it. </del> <ins> In this non-normative example, two tokens are issued under the names "token1" and "token2", and only the first token has a management URL associated with it. </ins> Each access token corresponds to one of the objects in the "access_token" array of the client instance's request-token-multiple.
Change:
Suggested changes for URL
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 5602b657d1be7c2b17685269030092799ccb120f https://deploy-preview-226--gnap-core-protocol-editors-URL
This PR is now pending merge, linking with a new issue for verification (to check the value based on typ).
Key proof sections do not currently detail how to verify each method, including requirements for verifying fields, this needs to be added.
The idea is to minimize ways to reuse JWS objects . These attacks are sometimes referred as Swapping JWTs and Cross-JWT Confusion). See also discussion in URL

Discussion:
To protect the request, the JOSE header MUST contain the following additional parameters. <ins> The type header, value "gnap-binding+jwsd". </ins> The HTTP Method used to make this request, as an uppercase ASCII string.

To protect the request, the JWS header MUST contain the following additional parameters. <ins> The type header, value "gnap-binding+jws". </ins> The HTTP Method used to make this request, as an uppercase ASCII string.
Change:
Replaces most examples by on email, as discussed in and
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 36777fd4186ad5d5f3d9e64c1120277ab52806d2 https://deploy-preview-228--gnap-core-protocol-editors-URL
Requesting User Information: Editor's Note: What we're really saying here is that "even if the AS gives you an email address to identify the user, that isn't a claim that this is a valid email address for that current user, so don't try to email them." In order to get a workable email address, or anything that you can use to contact them, you'd need a full identity protocol and not just this. Also, subject identifiers are asserted by the AS and therefore naturally scoped to the AS. Would changing the name to "assubids" or "localsubids" help convey that point?
Perhaps the example in this section should not include asking for the email here if we want to encourage asking for the email claim from OpenID instead.
NAME that's actually the core point of this issue: there's a semantic difference between asking for "tell me who the current user is, and I know them by an email address identifier" vs. "tell me the email address of the current user so that I can email them". The subject identifiers are the former, OpenID and other identity protocols would give you the latter.
See also .
It would be better to use examples that are not related to emails, to avoid confusion. I believe an "as_uid" (unique identifier local to the AS) could be best as an example that conveys the message.
Yaron: "Subject identifiers requested by the RC serve only to identify the RO in the context of the AS and can't be used as communication channels by the RC" - this sounds a bit naive, people will do that anyway. So why is this a useful statement? (And similarly in 3.4) Justin: This inclusion is based roughly off of a similar constraint in OIDC around subject identifiers: URL I agree that people will do dumb things anyway, but that’s why we need to spell out why it’s dumb here. Yaron: I haven't looked at the OpenID text, but at least here, we do not_ explain why using the email address to send email is a bad idea, we just say that it is. I think we should give a rationale.
There are many reasons why we don't want emails ("should not use email"). No assurance it's unique (ex: EMAIL) No idea on email policy (could be transfered to someone else) Ties to a delivery method (which shouldn't be our goal here) Also not using email facilitates the distinction with what OIDC/authentication mechanisms provide (more an internal argument for the specification text itself). Might also want to push forward privacy enhancing mechanisms.

Discussion:
response-interact.  [[ See issue #89 [34] ]] For example, if the request is successful in causing the AS to issue <del> access tokens and release subject claims, the response could look like this: </del> <ins> access tokens and release opaque subject claims, the response could look like this: </ins> With this example, the client instance can not make an additional continuation request because a "continue" field is not included.
Change:
Typo for section 1.4.3 Asynchronous Authorization, step 6: The continuation information was stored on step (2) not (3) as specified in the latest draft.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit befdba8ad92320248c4d011b13cca4f1dcb51f83 https://deploy-preview-245--gnap-core-protocol-editors-URL
Well spotted.

Discussion:
the RO that the request has been completed. Meanwhile, the client instance loads the continuation information <del> stored at (3) and continue-request.  The AS determines which </del> <ins> stored at (2) and continue-request.  The AS determines which </ins> ongoing access request is referenced here and checks its state. If the access request has not yet been authorized by the RO in
Change:
Fixes issue Note : in the appendix, I used "OAuth 2", elsewhere we talk about "OAuth 2.0". Maybe needs some adjustements.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 40ad74b8eeec1229a14c83324dbcce73533365d9 https://deploy-preview-247--gnap-core-protocol-editors-URL
For the RFC to be self-contained, please add a section to the Introduction (or an appendix) summarizing the main changes from OAuth2/OIDC, and the rationale for each delta. (Originally raised by NAME
Suggest to put this area in the wiki to have a deeper explanation
I've started a wiki page with some content I had written up for another publication: URL
This information is important to the draft's readership, and people are not seeing it (e.g., Denis's mail from March 26). Can we include it as-is in an appendix to the draft?
I will submit a PR as an appendix. Note also that the editors prepared a short paper "Managing authorization grants beyond OAuth 2" that has been accepted at . It was a nice way to get some external reviews. Will be published in
Looks good, just one typo to fix before inclusion.

Discussion:
around that ecosystem.  However, GNAP is not an extension of OAuth 2.0 and is not intended to be directly compatible with OAuth 2.0. GNAP seeks to provide functionality and solve use cases that OAuth <del> 2.0 cannot easily or cleanly address.  Even so, GNAP and OAuth 2.0 will exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP.  Some examples of these can be found in example- oauth2. </del> <ins> 2.0 cannot easily or cleanly address. vs-oauth2 further details the protocol rationale compared to OAuth 2.0.  GNAP and OAuth 2.0 will exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP.  Some examples of these can be found in example-oauth2. </ins> 1.1.
Change:
adds a paragraph to the introduction adds specific examples under roles
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit aa65f1110cdcc11a60ca4d2d284e78f7909d0817 https://deploy-preview-254--gnap-core-protocol-editors-URL

Discussion:
GNAP allows for the negotiation of the grant process over time by multiple parties acting in distinct roles. <ins> The focus of this protocol is to provide interopability between the different parties acting in each role, and is not to specify implementation details of each.  Where appropriate, GNAP may make recommendations about internal implementation details, but these recommendations are to ensure the security of the overall deployment rather than to be prescriptive in the implementation. </ins> This protocol solves many of the same use cases as OAuth 2.0 RFC6749, OpenID Connect OIDC, and the family of protocols that have grown up around that ecosystem.  However, GNAP is not an extension of OAuth

GNAP seeks to provide functionality and solve use cases that OAuth 2.0 cannot easily or cleanly address. vs-oauth2 further details the protocol rationale compared to OAuth 2.0.  GNAP and OAuth 2.0 will <del> exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP.  Some examples of these can be found in example-oauth2. </del> <ins> likely exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP.  Some examples of these can be found in example- oauth2. </ins> 1.1.

deployed cluster, then this cluster is considered a single client instance. <ins> In these cases, the distinct components of what is considered a GNAP client instance may use any number of different communication mechanisms between them, all of which would be considered an implementation detail of the client instances and out of scope of GNAP. </ins> For another example, an AS could likewise be built out of many constituent components in a distributed architecture.  The component that the client instance calls directly could be different from the <del> component that the the RO interacts with to drive consent, since API </del> <ins> component that the RO interacts with to drive consent, since API </ins> calls and user interaction have different security considerations in many environments.  Furthermore, the AS could need to collect identity claims about the RO from one system that deals with user attributes while generating access tokens at another system that deals with security rights.  From the perspective of GNAP, all of these are pieces of the AS and together fulfill the role of the AS as <del> defined by the protocol. </del> <ins> defined by the protocol.  These pieces may have their own internal communications mechanisms which are considered out of scope of GNAP. </ins> 1.3.
Change:
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 4080bf7a507929bd0ad4286d8ef72c0a70506c31 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Please ask the guy who submitted the vuln if there's any publication we can reference, maybe even the master's thesis as a WIP. They've earned it!
NAME I've reached out to them if there's a good URL to reference, and added them to the ack section (I should have done that before!).

Discussion:
this hash, and the client instance MUST validate the hash when received. <del> To calculate the "hash" value, the party doing the calculation first takes the "nonce" value sent by the client instance in the request- interact-finish, the AS's nonce value from response-interact-finish, and the "interact_ref" sent to the client instance's callback URL. These three values are concatenated to each other in this order using a single newline character as a separator between the fields.  There is no padding or whitespace before or after any of the lines, and no trailing newline character. </del> <ins> To calculate the "hash" value, the party doing the calculation creates a hash string by concatenating the following values in the following order using a single newline ("n") character to separate them: the "nonce" value sent by the client instance in the the AS's nonce value from the "interact_ref" returned from the AS as part of the the grant endpoint URL the client instance used to make its There is no padding or whitespace before or after any of the lines, and no trailing newline character. </ins> The party then hashes this string with the appropriate algorithm based on the "hash_method" parameter of the "callback".  If the
Change:
remove OAuth DPoP binding. Described why on IETF mailing list: OAuth PoP: expired draft, due to be replaced with new draft based on HTTP Message Signatures. Also closing and
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: a47cdeabae554f3636d63a0ce8e0f8b52ff53693 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Removed autoindent in my editor to fix the issue
OAuth Proof of Possession (PoP): Editor's note: This is a stale draft from the OAuth working group, but it does at least provide some basic functionality for protecting HTTP messages with a signature. This work is likely to be subsumed by the general-purpose HTTP message signature mechanism in Section 8.5.
OAuth Proof of Possession (PoP): Editor's note: This is in contradiction to the referenced spec which makes this field mandatory.

Discussion:
HTTP Signing signature header <del> OAuth PoP key proof authentication header </del> Additional proofing methods are defined by IANA. All key binding methods used by this specification MUST cover all

The verifier MUST validate the signature against the expected key of the signer. <del> 7.3.5. This method is indicated by "oauthpop" in the "proof" field.  The signer creates an HTTP Authorization PoP header as described in I- D.ietf-oauth-signed-http-request section 4, with the following additional requirements: The "at" (access token) field MUST be omitted unless this method is being used in conjunction with an access token as in use- access-token.  [[ See issue #112 [47] ]] The "b" (body hash) field MUST be calculated and included, if the message includes an entity body (such as a PUT or PATCH request). All components of the URL MUST be calculated and included, including query parameters "q", path "p", and host "u". The "m" (method) field MUST be included In this example, the request message body is the following JSON object The JOSE header for the PoP token is the following: After calculating the hashes for the body, headers, and URL components, the JWS Payload is the following: This leads to the following HTTP message request: [[ See issue #113 [48] ]] The verifier MUST parse the JWS object of the PoP header.  The verifier MUST validate the signature of the header against the expected key of the signer.  The verifier MUST ensure that all required parts of the message are covered by the signature.  The verifier MUST ensure that all components of the signature contain correct values. </del> 8. GNAP provides a rich structure for describing the protected resources

[45] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109 [46] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/110 <del> [47] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/112 [48] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/113 </del>
Change:
To align with secevent draft 8 which added DIDs
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 6ded21ad57eed6fd25df2ca4fb77dcf186c93209 :mag: Inspect the deploy log: :sunglasses: Browse the preview:

Discussion:
with a management URL and a response-subject in the form of an opaque identifier. <del> In this example, the AS is returning only a pair of response-subject as both an email address and an opaque identifier. </del> <ins> In this example, the AS is returning set of response-subject, simultaneously as an opaque identifier, an email address, and a decentralized identifier (DID). </ins> 3.1.