jiebi/CodeConvo huggingface dataset:
Change:
(thanks NAME
The example given for "attached JWS" in incorrect: missing JWS headers, incorrect value. Here's a better one for your base64 pleasure: eyJhbGciOiJSUzI1NiIsImtpZCI6IktBZ05wV2JSeXk5TWYycmlrbDQ5OExUaE1ydmtiWldIVlNRT0JDNFZIVTQiLCJodG0iOiJwb3N0IiwiaHR1IjoiL3R4IiwidHMiOjE2MDM4MDA3ODN9.eyJjYXBhYmlsaXRpZXMiOltdLCJjbGllbnQiOnsia2V5Ijp7Imp3ayI6eyJrdHkiOiJSU0EiLCJlIjoiQVFBQiIsImtpZCI6IktBZ05wV2JSeXk5TWYycmlrbDQ5OExUaE1ydmtiWldIVlNRT0JDNFZIVTQiLCJuIjoibGxXbUhGOFhBMktOTGRteE9QM2t4RDlPWTc2cDBTcjM3amZoejk0YTkzeG0yRk5xb1NQY1JaQVBkMGxxRFM4TjNVaWE1M2RCMjNaNTlPd1k0YnBNX1ZmOEdKdnZwdExXbnhvMVB5aG1Qci1lY2RTQ1JRZFRjX1pjTUY0aFJWNDhxcWx2dUQwbXF0Y0RiSWtTQkR2Y2NKbVpId2ZUcERIaW5UOHR0dmNWUDhWa0FNQXE0a1ZhenhPcE1vSVJzb3lFcF9lQ2U1cFN3cUhvMGRhQ1dOS1ItRXBLbTZOaU90ZWRGNE91bXQ4TkxLVFZqZllnRkhlQkRkQ2JyckVUZDR2Qk13RHRBbmpQcjNDVkN3d3gyYkFRVDZTbHhGSjNmajJoaHlJcHE3cGM4clppYjVqTnlYS3dmQnVrVFZZWm96a3NodC1Mb2h5QVNhS3BZVHA4THROWi13In0sInByb29mIjoiandzIn0sIm5hbWUiOiJNeSBGaXN0IENsaWVudCIsInVyaSI6Imh0dHA6Ly9sb2NhbGhvc3QvY2xpZW50L2NsaWVudElEIn0sImludGVyYWN0Ijp7ImNhbGxiYWNrIjp7Im1ldGhvZCI6InJlZGlyZWN0Iiwibm9uY2UiOiJkOTAyMTM4ODRiODQwOTIwNTM4YjVjNTEiLCJ1cmkiOiJodHRwOi8vbG9jYWxob3N0L2NsaWVudC9yZXF1ZXN0LWRvbmUifSwicmVkaXJlY3QiOnRydWV9LCJyZXNvdXJjZXMiOnsiYWN0aW9ucyI6WyJyZWFkIiwicHJpbnQiXSwibG9jYXRpb25zIjpbImh0dHA6Ly9sb2NhbGhvc3QvcGhvdG9zIl0sInR5cGUiOiJwaG90by1hcGkifSwic3ViamVjdCI6eyJzdWJfaWRzIjpbImlzcy1zdWIiLCJlbWFpbCJdfX0.LUyZ8fERmxbYARq8kBYMwzcd8GnCAKAlo2ZSYLRRNAYWPrp2XGLJOvg97WK1idfLB08OJmLVsCXxCvn9mgaAkYNLZjHcusBvY1mNo0E1sdTEr31CVKfC-6WrZCscb8YqE4Ayhh0Te8kzSng3OkLdy7xN4xeKuHzpF7yGsM52JZ0cBcTo6WrYEfGdr08AWQJ59ht72n3jTsmYNy9A6I4Wrvfgj3TNxmwYojpBAicfjnzA1UVcNm9FxiSz1y2tdH7j5rVqBMQife-k9Ewk95vr3lurthenliYSNiUinVfoW1ybnaIBcTtP1YCxg_h1y-B5uZEvYNGCuoCqa6IQ
At this stage, most of the examples need to be reworked and/or re-generated, especially including things with signatures. They were all originally pulled from a running system based on an older version of the I-D, and so edits to them have been by hand so far. This is a helpful start, so thanks!

Discussion:
content type of "application/jose".  The AS MUST extract the payload of the JWS and treat it as the request body for further processing. <ins> This example's JWS header decodes to: And the JWS body decodes to: </ins> If the request being made does not have a message body, such as an HTTP GET, OPTIONS, or DELETE method, the JWS signature is calculated over an empty payload and passed in the "Detached-JWS" header as
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: b88d66c00c5d10b7eacc0beb4dd928bbb94470a9 Inspect the deploy log: Browse the preview:
Good catch, thanks!

Discussion:
and MAY be more powerful.  The means for the RS to determine the resource reference are out of scope of this specification, but some dynamic methods are discussed in I-D.draft-ietf-gnap-resource- <del> servers.  The content of the resource handle is opaque to the client instance. </del> <ins> servers.  The content of the resource reference is opaque to the client instance. </ins> The client instance then makes a request to the "as_uri" as described in request, with the value of "access" as one of the members of the
Change:
Apostrophes were accidentally used instead of backticks to render the backslash as code.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ffdb4ee91464d098f38e69f9bd5e6936a5a009a8 Inspect the deploy log: Browse the preview:

Discussion:
This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and <del> other elements.  Some examples use a single trailing backslash '' to </del> <ins> other elements.  Some examples use a single trailing backslash "" to </ins> indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.
Change:
The backslash does not need to be escaped
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 1a3c389510f95bfaaf245f40e2552e735e30826b Inspect the deploy log: Browse the preview:

Discussion:
To calculate the "hash" value, the party doing the calculation creates a hash string by concatenating the following values in the <del> following order using a single newline ("n") character to separate </del> <ins> following order using a single newline ("n") character to separate </ins> them: the "nonce" value sent by the client instance in the
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: bf6004c8584efbaf8dc30f3637ba0c61bc000d84 Inspect the deploy log: Browse the preview:
NAME The editors would like to give you credit for all these contributions, can you please give us your name as you'd like it to appear in the acknowledgements section? Thank you!

Discussion:
token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been split by the AS, the value of the "label" field is chosen by the <del> AS and the "split" field is included and set to "true". </del> <ins> AS and the "split" flag is used. </ins> OPTIONAL.  The management URI for this access token.  If provided, the client instance MAY manage its access token as described in
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 88c9fdd493cc1d969e1405501ff6b7d071b218e9 Inspect the deploy log: Browse the preview:
In section 1.4, the text states: How can the AS "determine what is needed to fulfill the request" ? Shall the AS have established some prior relationship ? If yes, what such relationships consist of ? If no, can "other means" be used ?

Discussion:
(2) The client instance request. (3) The AS processes the request and determines what is needed to <del> fulfill the request.  The AS sends its response. </del> <ins> fulfill the request.  (See authorization.)  The AS sends its response. </ins> (B) If interaction is required, the AS authorization to gather authorization.  The interactive component of the AS can function
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 3ba5ef509380bf20fa220808c57fd1ced5797c5d Inspect the deploy log: Browse the preview:
This term is specific to the protocol, so should probably be defined
Background of picking a new term: The intended goal for the term as currently used is to generically talk about all the different methods of presenting proof of key possession by a client instance. Current methods include signature-based schemes that work on the HTTP message and a TLS-based scheme that relies on the key being the same between layers. These can all be optionally bound to an access token as well, and each "proof method" needs to have a way to include the access token in its coverage.
Renamed the issue for clarity. Please undo if I got it wrong.

Discussion:
In GNAP, the client instance secures its requests to the AS and RS by presenting an access token, presenting proof of a key that it <del> possesses, or both an access token and key proof together. </del> <ins> possesses (aka, a "key proof"), or both an access token and key proof together. </ins> When an access token is used with a key proof, this is a bound token request.  This type of request is used for calls to the RS
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 681a99c7e9be294002d224d914dbb452a5d278bf Inspect the deploy log: Browse the preview:

Discussion:
4.2.2. <del> When using the response-interact-finish with the "push" method, the AS signals to the client instance that interaction is complete and the request can be continued by sending an HTTP POST request to the client instance's callback URL sent in request-interact-callback- push. </del> <ins> When using the response-interact-finish, the AS signals to the client instance that interaction is complete and the request can be continued by sending an HTTP POST request to the client instance's callback URL sent in request-interact-callback-push. </ins> The entity message body is a JSON object consisting of the following two fields:

and no trailing newline character. The party then hashes this string with the appropriate algorithm <del> based on the "hash_method" parameter of the "callback".  If the </del> <ins> based on the "hash_method" parameter under the "finish" key.  If the </ins> "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3".
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 906ec0b0bbf3cdcb59850a43e4e9221456aa5eb8 Inspect the deploy log: Browse the preview:

Discussion:
The method the client instance uses to send an access token depends on whether the token is bound to a key, and if so which proofing <del> method is associated with the key.  This information is conveyed in the "bound" and "key" parameters in response-token-single and response-token-multiple responses. </del> <ins> method is associated with the key.  This information is conveyed by the "key" parameter and the "bearer" flag in response-token-single and response-token-multiple responses. </ins> If the "flags" field does not contain the "bearer" flag and the "key" is absent, the access token MUST be sent using the same key and
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 8641b302c594f5e2fd15576ceed1134a210465bd Inspect the deploy log: Browse the preview:

Discussion:
client software can include these values in their code for a more efficient and compact request. <del> If desired, the AS MAY also generate and return some of these references dynamically to the client instance in its response to facilitate multiple interactions with the same software.  The client instance SHOULD use these references in future requests in lieu of sending the associated data value.  These handles are intended to be used on future requests. Dynamically generated handles are string values that MUST be protected by the client instance as secrets.  Handle values MUST be unguessable and MUST NOT contain any sensitive information.  Handle values are opaque to the client instance. All dynamically generated handles are returned as fields in the root JSON object of the response.  This specification defines the following dynamic handle return, additional handles can be defined in IANA. </del> <ins> If desired, the AS MAY also generate and return an instance identifier dynamically to the client instance in the response to facilitate multiple interactions with the same client instance over time.  The client instance SHOULD use this instance identifier in future requests in lieu of sending the associated data values in the "client" field. Dynamically generated client instance identifiers are string values that MUST be protected by the client instance as secrets.  Instance identifier values MUST be unguessable and MUST NOT contain any sensitive information.  Instance identifier values are opaque to the client instance. </ins> A string value used to represent the information in the "client" object that the client instance can use in a future request, as described in request-instance. <del> This non-normative example shows one handle along side an issued access token. </del> <ins> This non-normative example shows an instance identifier along side an issued access token. </ins> [[ See issue #77 [18] ]]
Change:
May later make a link to security considerations related to phishing attacks but currently the section has not been merged in trunk, so it would create an error
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 0dd7278bfa3604409da8bb8ea4ddc6983824cdb2 Inspect the deploy log: Browse the preview:
To be described (interactions)

Discussion:
software.  However, end-users might also be facing some attacker's client software, without even realizing it. <ins> end-user / AS: when the client supports it (see response- interact), the end-user gets to interact with front-channel URLs provided by the AS. </ins> client/AS: An honest AS may be facing an attacker's client (as discussed just above), or the reverse, and GNAP aims at making common attacks impractical.  The core specification makes access
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 8fe956adfc5cb03ad39042fa3e3497c42d7fbce1 Inspect the deploy log: Browse the preview:
Some unicode characters within the document break the build tools, specifically we see being changed to in the rendered document.

Discussion:
validates the hash.  If the client instance does not use an interaction finish method or does not check the interaction finish hash value, the compromised AS can be granted a valid access token on <del> behalf of the resource owner.  See attack-surfaces for details of one </del> <ins> behalf of the resource owner.  See AXELAND2021 for details of one </ins> such attack, which has been since addressed in this document by including the grant endpoint in the interaction hash calculation. The client instance still needs to validate the hash for the attack
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ca9e3193f78b420b40659157f6d18545ddc97e80 Inspect the deploy log: Browse the preview:
Originally posted by NAME in URL
In general I would tend to think this doesn't need to be specified by us, supporting the current text "The means of dereferencing this value are out of scope for this specification." But before we can conclude, I'd like to ask a few questions: related the lifecycle of the referenced key (cf ) : is it something ephemeral (linked to a specific request) or not ? (but knowing that continuation could last for some time, what do we do then?) could it have an impact on error management? (for instance collision of references?)
In draft 7, says that dereferencing key references are out of scope. Add to 7.1.1 to clarify: The common case is such that key references are created by the AS and are not necessarily deferenceable by the client, they are just an internal AS reference If an implementation (or ecosystem of implementations) wants to use references that are resolvable by both clients and ASs (i.e. the client publishes its key at a URL), that could be described as an extension
I think the text looks good, left one note on formatting/structure but it's not a showstopper.

Discussion:
mechanism. The means of dereferencing this value are out of scope for this <del> specification. </del> <ins> specification.  Commonly, key references are created by the AS and are not necessarily needed to be dereferencable by the client.  These types of key references are an internal reference to the AS, such as an identifier of a record in a database.  In other applications, it can be useful to use key references that are resolvable by both clients and ASs, which could be accomplished by e.g. a client publishing a public key at a URL.  For interoperability, this method could later be described as an extension. </ins> 7.2.
Change:
with array of objects to account for the possibility of several assertions
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 92ab3a878b0995957e39ff9c8cae0726a0fd3f44 Inspect the deploy log: Browse the preview:
As a completely random comment, I find it interesting that computer science commonly refers to an array as a collection of elements with the same data type. It's also a fixed-size collection of elements. URL clearly defines and uses an array. Moreover, it says that what's a bit more important is that this specification should probably use "array of ..." everywhere as this isn't true right now. I see the use of both "list of ..." and "array of ..." at the same time.
Since GNAP is based around JSON for its data model, we use JSON-native data types and their names. The name for an unlabeled, ordered collection is a "JSON array", as you pointed out. If there are places in GNAP where we're using "list" where we should be saying "array", we should fix that.
Todo : inner description to change (key) assertions -> format subid_formats or something like that
Requesting User Information: Editor's note: The values are lifted from ]'s "token type identifiers" list, but is there a better source? : Identifying the User: Editor's note: The keys are lifted from [RFC8693]'s "token type identifiers" list, but is there a better source? Additionally: should this be an array of objects with internal typing like the subids? Do we expect more than one assertion per user anyway? Returning User Information: Editor's note: Should be an array of objects with internal typing like the subids? Do we expect more than one assertion per user anyway?
A related topic is , ZKP, etc. A specific type of assertion is used in to prove ownership of a sub (through JWT).
I think that should be an in "Returning User Information". If not, at least, it could be renamed to "assertion" because the current draft uses "assertions" and defines it as . This is a minor editorial thing though. The more major thing is that what are the strong reasons even to mention SAML assertions in the spec? In recent times, XML is often referred to as a potentially insecure format which isn't great due to a long list of vulnerabilities in XML libraries.
We'll discuss that and more at IETF110. I agree that assertions are probably an array (it's not just editorial, and there's another issue open on that) + for the very same reasons you mention I would suggest we remove saml2 assertions from the core (but still we can plan an extension in the registry, already mentioned as a possibility ).
There's now a security consideration related to XML.

Discussion:
The AS SHOULD NOT re-use subject identifiers for multiple different ROs. <del> Note: the "formats" and "assertions" request fields are independent of each other, and a returned assertion MAY use a different subject identifier. </del> <ins> Note: the "sub_id_formats" and "assertion_formats" request fields are independent of each other, and a returned assertion MAY use a different subject identifier. </ins> [[ See issue #43 [1] ]]
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 00127788e68e6777c3e674eb44e3a821cb54516e Inspect the deploy log: Browse the preview:
in 4.2.3.1 and 4.2.3.2, for base64 encoded URLs with no padding (+ by the way, we should explain what we mean by no padding and URL safe)
Base64 URL-safe encoding, with and without padding, is defined in RFC4648. URLsafe: URL Optional padding: URL
thanks exactly the links i needed

Discussion:
The "sha3" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL <del> Safe Base64 with no padding.  The resulting string is the hash value. </del> <ins> Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> 4.2.3.2. The "sha2" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL <del> Safe Base64 with no padding.  The resulting string is the hash value. </del> <ins> Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> 5.
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 72feabe3d5e229b7516edd76777e3186dfd09f91 Inspect the deploy log: Browse the preview:
Still need to explain better how to do that, will track as part of lifecycle discussion
explains how an existing request can be modified by a PATCH request to the continuation endpoint. My question is, what happens if such a PATCH request is sent while the interaction for the associated grant request is not yet finished? I feel like this should not be allowed, but could not find any information anywhere in Section 5 that this is actually forbidden. Section 5.3 also says that the PATCH request may include post-interaction responses. I assume this means that by specifying an interaction reference in the PATCH request the interaction can be finished by the PATCH request, so the question would be what happens if the interaction is not finished and the PATCH request does not contain an interaction reference?
In Section 3.3.4 it says If the PATCH request is considered a continuation request (which is reasonable since it is sent to the continuation URI), this would prohibit a PATCH request before the interaction finishes. However, if no interaction finish mode is used, this does not apply.
I believe the cases are covered (a PATCH can't be done when it is pending), even if we could make things clearer probably : using PATCH instead of POST aims to provide better signal/control of when the partial update can be made as part of a continuation request (and it needs to use the continue access token) when the client can't receive a finish method (redirect or push), then it will need to poll regularly (cf 5.2)
Summary from editor's discussion: The grant process is stateful, a grant goes from (requested) -> (pending approval) -> (approved), at least. The PATCH request only makes sense to an (approved) grant, the post-interaction requests only make sense for the (pending) grant. We can call out this stateful nature and constrain different requests and inputs to specific states.
Proposed solution to make a state diagram and add state description in the overall protocol discussion.
Modifying an Existing Request: Editor's note: The net result of this is that interaction requests are really only meant to be responded to exactly once by the AS. This isn't spelled out explicitly, but could be included in Section 2.5 and/or Section 3.3.
This feeds into the overall discussion of "what can be sent when" and the lifecycle of the grant within the API; I do think that these artifacts should be one-time-use, especially the nonces.

Discussion:
error since the client instance will be unable to complete the request without authorization. <del> The AS SHOULD apply suitable timeouts to any interaction mechanisms </del> <ins> The AS SHOULD handle any interact request as a one-time-use mechanism and SHOULD apply suitable timeouts to any interaction mechanisms </ins> provided, including user codes and redirection URLs.  The client instance SHOULD apply suitable timeouts to any callback URLs.