jiebi/CodeConvo huggingface dataset:
Change:
Actually a very minor editorial change to specify the actions.
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: b874cebd8f241746631e4c73c3c9056b190bfb1e Inspect the deploy log: Browse the preview:
So I was starting to have a look at rotation/revocation issues (keys or tokens), as we have many open issues that relate to that Interesting insight from DIF KERI (Universal Identifier Theory paper) "The term revocation has two completely different meanings in the identity space. In key management one may speak of revoking keys. With statement issuance, authorization issuance, or credential issuance, one may speak of revoking an authorization statement, a token, or a credential. This becomes confusing when the act of revoking keys also implicitly revokes the authorization of statements signed with those keys." and "KERI terminology usually avoids that confusion between rotation and revocation because a key rotation operation is the equivalent of a key revocation operation followed by a key replacement operation. So one operation, rotate, is implemented instead of two operations (revoke and replace)."
Related question: what is persistent (drawback, need to store that info somewhere, safely) ? what is ephemeral ? what's the lifecycle of related objects? And more specifically: every new request needs to provide a key -> don't need long term persistance for that, we simply need to handle key rotations during a single request (as described in issue ) objets derived from some underlying key however (including bound tokens) might be more tricky ( ex ). Do we need some kind of registry to keep track of the changes over time, to keep them alive even if the key changes? Or do we just consider that they get revoked? (and what happens if you fall into that case at some point, what's your next action?)
This is already managed by section 7.2 "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 proofing mechanism that the client instance used in its initial request (or its most recent rotation)"

Discussion:
If an access token response includes the "manage" parameter as described in response-token-single, the client instance MAY call this URL to manage the access token with any of the actions defined in the <del> following sections.  Other actions are undefined by this specification. </del> <ins> following sections: rotate and revoke.  Other actions are undefined by this specification. </ins> The access token being managed acts as the access element for its own management API.  The client instance MUST present proof of an
Change:
The specification can also say a bit stricter A response MUST use the 200 OK (HTTP status code) and return a JSON object using content type.
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 9f7633b4fd5b90bbac20a33ade1e56045a47b3c1 Inspect the deploy log: Browse the preview:

Discussion:
client instance wants to optimize its calls to the AS before making a request, it MAY send an HTTP OPTIONS request to the grant request endpoint to retrieve the server's discovery information.  The AS MUST <del> respond with a JSON document containing the following information: </del> <ins> respond with a JSON document with Content-Type "application/json" containing a single object with the following information: </ins> The information returned from this method is for optimization purposes only.  The AS MAY deny any request, or any portion of a
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 7e9a352ebd6b48adb5f0a834a94bd083c38cb53c Inspect the deploy log: Browse the preview:
The text says: protected by the client instance as secrets. Instance identifier values MUST be unguessable and MUST NOT contain any sensitive information. This is weird, because we're saying both that they should be treated as secrets and that they are not sensitive. I would suggest instead: protected by the client instance as secrets. Instance identifier values MUST be unguessable and MUST NOT contain any information that would compromise the AS if revealed.
We're not saying that they're not sensitive, we're saying that they can't contain sensitive information. This is like saying your password is sensitive and it also shouldn't contain your medical record number at your hospital, because that's also a sensitive piece of information. Still I think the wording is an improvement, thanks!
I agree the proposed wording is better, thanks !

Discussion:
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 <del> sensitive information.  Instance identifier values are opaque to the client instance. </del> <ins> information that would compromise any party if revealed.  Instance identifier values are opaque to the client instance. </ins> This non-normative example shows an instance identifier along side an issued access token.
Change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: a48ba2e1204e2294f34f8550971f65f684ea7992 Inspect the deploy log: Browse the preview:
Sec. 1.5 (Sequences) would be clearer if we named the top sequence - all other sequences have been named. Maybe "main authorization flow"?
The sequences have not been names per say, they just happen to be related to a subtitle. We could of course create a new subsection, but the idea was to place this sequence above the others.
This is purely editorial. Naming it would make it easier to refer to this sequence.

Discussion:
could be calling the AS just to get direct user information and have no need to get an access token to call an RS. <ins> 1.5.1. The following diagram provides a general overview of GNAP, including many different optional phases and connections.  The diagrams in the following sections provide views of GNAP under more specific circumstances. </ins> (A) The end user interacts with the client instance to indicate a need for resources on behalf of the RO.  This could identify the RS the client instance needs to call, the resources needed, or the

and never call an RS, just as it is possible for there not to be a user involved in the delegation process. <del> 1.5.1. </del> <ins> 1.5.2. </ins> In this example flow, the client instance is a web application that wants access to resources on behalf of the current user, who acts as

An example set of protocol messages for this method can be found in example-auth-code. <del> 1.5.2. </del> <ins> 1.5.3. </ins> In this example flow, the client instance is a device that is capable of presenting a short, human-readable code to the user and directing

An example set of protocol messages for this method can be found in example-device. <del> 1.5.3. </del> <ins> 1.5.4. </ins> In this example flow, the end user and RO roles are fulfilled by different parties, and the RO does not interact with the client

An example set of protocol messages for this method can be found in example-async. <del> 1.5.4. </del> <ins> 1.5.5. </ins> In this example flow, the AS policy allows the client instance to make a call on its own behalf, without the need for an RO to be

An example set of protocol messages for this method can be found in example-no-user. <del> 1.5.5. </del> <ins> 1.5.6. </ins> In this example flow, the client instance receives an access token to access a resource server through some valid GNAP process.  The client

token management information, which the client instance will store in place of the values returned in (2). <del> 1.5.6. </del> <ins> 1.5.7. </ins> In this scenario, the client instance does not call an RS and does not request an access token.  Instead, the client instance only
Change:
updated examples updated examples for httpsig
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: a6cdcdcaf974e575a7e246dca7ada0e9b72e25cf Inspect the deploy log: Browse the preview:

Discussion:
In this example, the AS is returning set of response-subject, simultaneously as an opaque identifier, an email address, and a <del> decentralized identifier URL (DID). </del> <ins> decentralized identifier (DID). </ins> 3.1.
Change:
Instead of using an object with a single member, the interaction start method now uses a simple string, in line with the and methods.
To edit notification comments on pull requests, go to your .

Discussion:
If the client instance indicates that it can request-interact- usercode and the AS supports this mode for the client instance's <del> request, the AS responds with a "user_code" field.  This field is an object that contains the following members. The client instance MUST communicate the "code" to the end user in some fashion, such as displaying it on a screen or reading it out audibly.  This code is used by the interaction component of the AS as a means of identifying the pending grant request and does not </del> <ins> request, the AS responds with a "user_code" field.  This field is string containing a unique short code that the user can type into a web page.  This string MUST be case-insensitive, MUST consist of only easily typeable characters (such as letters or numbers).  The time in which this code will be accepted SHOULD be short lived, such as several minutes.  It is RECOMMENDED that this code be no more than eight characters in length.  REQUIRED. The client instance MUST communicate the "user_code" value to the end user in some fashion, such as displaying it on a screen or reading it out audibly.  This code is used by the interaction component of the AS as a means of identifying the pending grant request and does not </ins> function as an authentication factor for the RO. The URI that the end user is intended to enter the code into MUST be
Change:
Allows interaction responses from the AS to have an explicit timeout, with instructions on how the client instance can recover (do a modification).
To edit notification comments on pull requests, go to your .
When an AS creates a set of of interaction artifacts, like a user code or interaction URI, these artifacts aren't likely to be available perpetually. The AS will likely want to purge these after some time. It might be useful for the AS to indicate to the client a timeout for the "interact" return block so that the client has some idea of how much time it has to use the interaction methods.

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

state, the client instance can repeat the interaction process by sending a continue-modify with new request-interact methods. <ins> The AS SHOULD handle any interact request as a one-time-use mechanism and SHOULD apply suitable timeouts to any interaction start methods provided, including user codes and redirection URIs.  The client instance SHOULD apply suitable timeouts to any interaction finish method. </ins> 4.1. When a grant request is in the

be used to facilitate interaction with the end user.  To initiate an interaction start method indicated by the response-interact from the AS, the client instance follows the steps defined by that interaction <del> method.  The actions of the client instance required for the </del> <ins> start mode.  The actions of the client instance required for the </ins> interaction start modes defined in this specification are described <del> in the following sections. </del> <ins> in the following sections.  Interaction start modes defined in extensions to this specification MUST define the expected actions of the client software. If the client instance does not start an interaction start mode within an AS-determined amount of time, the AS SHOULD reject attempts to use the interaction start modes.  If the client instance has already begun one interaction start mode, the AS SHOULD reject attempts to use other interaction start modes. </ins> 4.1.1.
Change:
To edit notification comments on pull requests, go to your ._
Receive a Callback After Interaction: Editor's note: This should be expandable via a registry of cryptographic options, and it would be good if we didn't define our own identifiers here. Calculating the interaction hash: Editor's note: These hash algorithms should be pluggable, and ideally we shouldn't redefine yet another crypto registry for this purpose, but I'm not convinced an appropriate one already exists. Furthermore, we should be following best practices here whether it's a plain hash, a keyed MAC, an HMAC, or some other form of cryptographic function. I'm not sure what the defaults and options ought to be, but SHA512 and SHA3 were picked based on what was available to early developers.
This is probably the right registry to reference: URL
Please add a changelog, but this looks good to me!

Discussion:
and no trailing newline character. The party then hashes this string with the appropriate algorithm <del> based on the "hash_method" parameter under the "finish" key.  If the "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3". [[ See issue #56 [11] ]] </del> <ins> based on the "hash_method" parameter under the "finish" key.  The resulting byte array from the hash function is then encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> <del> 4.2.3.1. </del> <ins> The "hash_method" value MUST be one of the hash name strings defined in the IANA Named Information Hash Algorithm Registry [11]. </ins> <del> The "sha3" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </del> <ins> If the "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3-512". </ins> <del> 4.2.3.2. </del> <ins> For example, the "sha3-512" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> <del> The "sha2" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL Safe Base64 with no padding RFC4648.  The resulting string is the </del> <ins> The "sha2-512" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the </ins> hash value. 5.

[10] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/78 <del> [11] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/56 </del> <ins> [11] https://www.iana.org/assignments/named-information/named- information.xhtml#hash-alg </ins> [12] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/85
Change:
Requires all URIs to be absolute throughout the protocol.
To edit notification comments on pull requests, go to your ._
While it doesn't say so in the spec and the example suggest otherwise, are relative URLs allowed for properties such as the response. Scenario, an implementation is deployed at a URL: URL The root of the server handles grant requests: to The application code that builds the response must be able to construct the full URL and therefor have knowledge of the host at which the application is deployed including any path prefix. This is not impossible, but in complex cloud deployments with load balancers and ingress services etc between the application code and the public endpoint this can get ugly. The current example from Section 3.1 of the spec. Implementations would be significantly easier to build if they could simply return:
To be clear, the base URL for any relative URL response would be the request URL.
Things get really tricky if you start to allow for things like directory ascension (../../continue) and other such things. Lots of attacks in the past stem from exploitation of devices like this. Application deployments that deal with external urls already have techniques for managing such urls, from proxy rewrites to internal configuration. With these together I don't see a good argument for this being anything but an absolute uri.
Is it necessary to state somewhere that all URIs are absolute?
Yes, we should say exactly that, that's why I am keeping this issue open. Thanks for pointing this out!
Makes sense

Discussion:
As this interaction mode is designed to facilitate interaction via a secondary device, it is not expected that the client instance <del> redirect the end user to the URL given here at runtime.  If the </del> <ins> redirect the end user to the URI given here at runtime.  If the </ins> client instance is capable of communicating an short arbitrary URI to the end user for use with the user code, the client instance can instead use the request-interact-usercodeuri method instead.  If the
Change:
To edit notification comments on pull requests, go to your .
Yaron: "Speculative" access ("Requesting a Resources With Insufficient Access") is not useful if the response is only a MAY. Why would the RC try it if it is unlikely to provide useful information? Justin: I think the MAY is not quite the right normative application here. It’s a MUST if you’re doing it to do it in this way, but it’s not a MUST for all RS’s everywhere to respond in this fashion. If the RC tries calling an RS that doesn’t respond with this, the RC simply doesn’t know, from any programmatic or automated way, what to do to make the request actually work. Yaron: Sounds like a SHOULD to me - then an RC can assume with reasonable confidence that a random RS will implement it.

Discussion:
9.1. If the client instance calls an RS without an access token, or with <del> an invalid access token, the RS MAY respond to the client instance with an authentication header indicating that GNAP needs to be used to access the resource.  The address of the GNAP endpoint MUST be sent in the "as_uri" parameter.  The RS MAY additionally return a resource reference that the client instance MAY use in its access </del> <ins> an invalid access token, the RS SHOULD respond to the client instance with a WWW-Authenticate header field indicating that GNAP needs to be used to access the resource.  The address of the GNAP endpoint MUST be sent in the "as_uri" parameter.  The RS MAY additionally return a resource reference that the client instance SHOULD use in its access </ins> token request.  This resource reference MUST be sufficient for at least the action the client instance was attempting to take at the RS and MAY be more powerful.  The means for the RS to determine the
Change:
Built To edit notification comments on pull requests, go to your .
Please take a look a BCP 107 (a.k.a. RFC 4107). You may need a reference here. Originally posted by NAME in URL
Ok but should this text be updated ? In 2005, potential quantum threats were not even anticipated (with impacts on key size for instance)
I think the overall message remains accurate, but you are right that quantum computing was not a concern when RFC 4107 was written. Any updates to RFC 4107 are not part of your task in the GNAP WG.
Sure, thanks for the feedback.

Discussion:
The cryptographic methods used by GNAP for key-proofing can support both asymmetric and symmetric cryptography, and can be extended to <del> use a wide variety of mechanisms.  While symmetric cryptographic systems have some benefits in speed and simplicity, they have a distinct drawback that both parties need access to the same key in order to do both signing and verification of the message.  This means that when the client instance calls the AS to request a token, the AS needs to know the exact value of the client instance's key (or be able to derive it) in order to validate the key proof signature. With asymmetric keys, the client needs only to send its public key to the AS to allow for verification that the client holds the associated private key, regardless of whether that key was pre-registered or not with the AS. </del> <ins> use a wide variety of mechanisms.  Implementers will find useful the available guidelines on cryptographic key management provided in RFC4107.  While symmetric cryptographic systems have some benefits in speed and simplicity, they have a distinct drawback that both parties need access to the same key in order to do both signing and verification of the message.  This means that when the client instance calls the AS to request a token, the AS needs to know the exact value of the client instance's key (or be able to derive it) in order to validate the key proof signature.  With asymmetric keys, the client needs only to send its public key to the AS to allow for verification that the client holds the associated private key, regardless of whether that key was pre-registered or not with the AS. </ins> When used to bind to an access token, a key value must be known by the RS in order to validate the proof signature on the request.
Change:
Built To edit notification comments on pull requests, go to your ._
The discovery process defined in GNAP details how to get information about the AS once you know the grant endpoint and can talk directly to it. We do not cover how to get the grant endpoint, except in the one case of it being provided by the RS at runtime in a response. The core document should at least discuss this gap as intentional, and an extension specification (or several) could be written to fill this gap in different circumstances.

Discussion:
If issued, the resulting access token would contain sufficient access to be used at both referenced resources. <ins> 9.2. Additional methods of discovering the appropriate grant endpoint for a given application are outside the scope of this specification. This limitation is intentional, as many applications rely on static configuration between the client instance and AS, as is common in OAuth 2.0.  However, the dynamic nature of GNAP makes it a prime candidate for other extensions defining methods for discovery of the appropriate AS grant endpoint at runtime.  Advanced use cases could define contextual methods for contextually providing this endpoint to the client instance securely.  Furthermore, GNAP's design intentionally requires the client instance to only know the grant endpoint and not additional parameters, since other functions and values can be disclosed and negotiated during the grant process. </ins> 10. The editors would like to thank the feedback of the following