jiebi/CodeConvo huggingface dataset:
Code change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:

Related discussion:
text: In some circumstances, the information needed at a given stage is communicated out of band or is preconfigured between the components <del> or entities performing the roles.  For example, one entity can fulfil multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.  Additionally some components may not be involved in all use cases.  For example, a client instance could be calling the AS just to get direct user information and have no need to get an access token to call an RS. </del> <ins> or entities performing the roles.  For example, one entity can fulfill multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.  Additionally some components may not be involved in all use cases.  For example, a client instance 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.
Code change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:

Related discussion:
text: The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction- <del> redirect given by the AS in (2). </del> <ins> usercode given by the AS in (2). </ins> <del> The user's directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </del> <ins> The users directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </ins> documentation, the AS documentation, or the client software itself.  Since it is assumed that the RO will interact with the AS through a secondary device, the client instance does not provide a
Code change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:

Related discussion:
text: The client instance request.  The client instance does not send any interaction modes to the server. <del> The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to the client instance.  Note that response-subject is not generally </del> <ins> The AS determines that the request has been authorized, the AS grants access to the resource in the form of response-token to the client instance.  Note that response-subject is not generally </ins> applicable in this use case, as there is no user involved. The client instance use-access-token to call the RS.
Code change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:

Related discussion:
text: the RS again. The RS validates the access token and determines that the access <del> token is expired The RS responds to the client instance with an </del> <ins> token is expired.  The RS responds to the client instance with an </ins> error. The client instance calls the token management URI returned in (2)
Code change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:

Related discussion:
text: 2. <del> To start a request, the client instance sends RFC8259 document with </del> <ins> To start a request, the client instance sends a RFC8259 document with </ins> an object as its root.  Each member of the request object represents a different aspect of the client instance's request.  Each field is described in detail in a section below. Additional members of this request object can be defined by <del> extensions to this protocol as described in </del> <ins> extensions to this protocol as described in request-extending. </ins> A non-normative example of a grant request is below:
Code change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:

Related discussion:
text: to determine appropriate key information, the client instance can send this instance identifier as a direct reference value in lieu of the "client" object.  The instance identifier MAY be assigned to a <del> client instance at runtime through the response-dynamic-handles or MAY be obtained in another fashion, such as a static registration process at the AS. </del> <ins> client instance at runtime through a grant response (response- dynamic-handles) or MAY be obtained in another fashion, such as a static registration process at the AS. </ins> When the AS receives a request with an instance identifier, the AS MUST ensure that the key used to binding-keys is associated with the
Code change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:

Related discussion:
text: In response to a client instance's request, the AS responds with a JSON object as the HTTP entity body.  Each possible field is detailed <del> in the sections below </del> <ins> in the sections below. </ins> In this example, the AS is returning an response-interact-redirect, a response-interact-finish, and a response-continue.
Code change:
Update all diagrams to use AASVG for rendering in HTML.
To edit notification comments on pull requests, go to your ._

Related discussion:
text: it can request-interact-usercode. The AS determines that interaction is needed and response with a <del> response-interact-usercode.  This could optionally include a URI to direct the user to, but this URI should be static and so could be configured in the client instance's documentation.  The AS also includes information the client instance will need to response- continue in (8) and (10).  The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </del> <ins> response-interact-usercode.  The AS also includes information the client instance will need to response-continue in (8) and (10). The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </ins> The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction-
Code change:
Update all diagrams to use AASVG for rendering in HTML.
To edit notification comments on pull requests, go to your ._

Related discussion:
text: any interaction modes to the server, indicating that it does not expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using <del> the request-user. </del> <ins> the request-user.  It's also possible for the AS to determine which RO needs to be contacted by the nature of what access is being requested. </ins> The AS determines that interaction is needed, but the client instance cannot interact with the RO.  The AS response with the
Code change:
After discussion with NAME , this PR now makes keys single-format-only as previously suggested.
To edit notification comments on pull requests, go to your ._
Yaron: why are we sending a JWK as well as a cert? Are we checking that the cert contains the same public key as the cert? Justin: I would be OK with the different formats being mutually exclusive somehow. The AS would need to check that they’re the same and throw an error if not. But this would also let the RC send over whatever it’s got for its own keys every time.
The document has been changed to address this issue, copying my text that refers to the latest draft version: In Sec. 7.1 we allow the client to include multiple keys of different formats, provided they are "equivalent". This doesn't make sense, because the only reason to send multiple keys is that the sender suspects that the recipient doesn't understand one of the formats. But if that's the case, the recipient is not able to validate the MUST requirement that the two formats be equivalent. This could also lead to interesting key injection attacks. IMO we should only allow one key value/format for each request.

Related discussion:
text: response-token-single, the proof of that key MUST be used when presenting the access token. <del> A key presented by value MUST be a public key in at least one supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key.  See additional discussion of public keys in security-symmetric. A key presented by value MUST be a public key in at least one supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key. </del> <ins> A key presented by value MUST be a public key and MUST be presented in one and only one supported format, as discussed in security- multiple-key-formats.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key.  See additional discussion of the presentation of public keys in security-symmetric. </ins> Additional key formats are defined in the IANA-key-formats. <del> This non-normative example shows a single key presented in multiple formats.  This example key is intended to be used with the httpsig- binding proofing mechanism, as indicated by the "httpsig" value of the "proof" field. </del> <ins> This non-normative example shows a single key presented in two different formats.  This example key is intended to be used with the httpsig-binding proofing mechanism, as indicated by the "httpsig" value of the "proof" field. As a JSON Web Key: As a certificate in PEM format: </ins> 7.1.1.
Code change:
After discussion with NAME , this PR now makes keys single-format-only as previously suggested.
To edit notification comments on pull requests, go to your ._
Yaron: why are we sending a JWK as well as a cert? Are we checking that the cert contains the same public key as the cert? Justin: I would be OK with the different formats being mutually exclusive somehow. The AS would need to check that they’re the same and throw an error if not. But this would also let the RC send over whatever it’s got for its own keys every time.
The document has been changed to address this issue, copying my text that refers to the latest draft version: In Sec. 7.1 we allow the client to include multiple keys of different formats, provided they are "equivalent". This doesn't make sense, because the only reason to send multiple keys is that the sender suspects that the recipient doesn't understand one of the formats. But if that's the case, the recipient is not able to validate the MUST requirement that the two formats be equivalent. This could also lead to interesting key injection attacks. IMO we should only allow one key value/format for each request.

Related discussion:
text: SSRF is somewhat more difficult to manage at runtime, and systems should generally refuse to fetch a URI if unsure. <ins> 12.33. Keys presented by value are allowed to be in only a single format, as discussed in key-format.  Presenting the same key in multiple formats is not allowed and is considered an error in the request.  If multiple keys formats were allowed, receivers of these key definitions need to be able to make sure that it's the same key represented in each field and not simply use one of the key formats without checking for equivalence.  If equivalence were not carefully checked, it is possible for an attacker to insert their own key into one of the formats without needing to have control over the other formats.  This could potentially lead to a situation where one key is used by part of the system (such as identifying the client instance) and a different key in a different format in the same message is used for other things, like calculating signature validity. To combat this, all keys presented by value have to be in exactly one supported format known by the receiver.  Normally, a client instance is going to be configured with its keys in a single format, and it will simply present that format as-is to the AS in its request.  A client instance capable of multiple formats can use discovery to determine which formats are supported, if desired.  An AS should be generous in supporting many different key formats to allow different types of client software and client instance deployments. </ins> 13. The privacy considerations in this section are modeled after the list
Code change:
Adds the field for requesting information for a specific user, separate from identifying the current end-user. Also adds a security considerations section addressing asynchronous authorization methods.
To edit notification comments on pull requests, go to your .
Normally we think about releasing subject information being about the current end-user, but that's not necessarily universal. The use case from CIBA: Alice is a support engineer with a company Bob is a customer of that company Bob calls the company and talks to Alice Alice needs to authenticate, from her system, that Bob is the person tied to the account in question Alice's client messages the AS to request Bob's information (probably including an identifier for Bob in the request) The AS reaches out to Bob to approve Alice's client to get Bob's information Bob approves Alice's request (probably on a pre-enrolled device) The AS sends Bob's information back to Alice's client Note a few key assumptions with this: At no point does Alice's client think that Bob is logging in. Alice and Bob both need accounts of some type at the AS Alice's account (or client) need the rights to request someone else's info Bob's approval mechanism needs to be tied to his account ahead of time (since Bob isn't running the client and the AS needs to reach out to him out of band) Bob's approval needs to be clearly directed to tell Bob that it's Alice (and alice's client) asking for his info Alice might need to log in / interact with the AS as part of this, or it might be tied to the client instance (maybe Alice has logged in for the day and that association is remembered by the AS?)
This is an interesting use case. Yet CIBA doesn't necessarily require an AS to work, as long as one is only interested in getting scopes. Is there a generic use case for cross-user subject information + required AS? Or maybe we should explain the added value of the AS in that specific case ?
We will add an example in section D that shows how this would work and verify that the language around subject identifiers is sufficiently robust to encapsulate this. This might also add additional security and privacy considerations when used in this mode because multiple people are now involved explicitly.
I think this could be marked as NEEDS TEXT ?
I think it mostly just needs to be added as an example, and I can do that.
Fine ;-) (on my side, I always tend to consider CIBA as some degenerate phishing experiment, but maybe that's too extreme)

Related discussion:
text: An example set of protocol messages for this method can be found in example-async. <ins> Additional considerations for asynchronous interactions like this are discussed in security-async. </ins> 1.6.5. In this example flow, the AS policy allows the client instance to
Code change:
Just two minor typos I stumbled across.
Built To edit notification comments on pull requests, go to your .

Related discussion:
text: 4.2. If an interaction response-interact-finish method is associated with <del> the current request, the AS MUST follow the appropriate method at upon completion of interaction in order to signal the client instance to continue, except for some limited error cases discussed below.  If a finish method is not available, the AS SHOULD instruct the RO to </del> <ins> the current request, the AS MUST follow the appropriate method upon completion of interaction in order to signal the client instance to continue, except for some limited error cases discussed below.  If a finish method is not available, the AS SHOULD instruct the RO to </ins> return to the client instance upon completion. The AS MUST create an interaction reference and associate that
Code change:
Just two minor typos I stumbled across.
Built To edit notification comments on pull requests, go to your .

Related discussion:
text: appropriate cryptographic processes to ensure the integrity of the assertion. <del> For example, when SAML 2 assertions are used, the receiver hast to </del> <ins> For example, when SAML 2 assertions are used, the receiver has to </ins> parse an XML document.  There are many well-known security vulnerabilities in XML parsers, and the XML standard itself can be attacked through the use of processing instructions and entity
Code change:
clarify that user codes are unguessable, - update user code examples,
To edit notification comments on pull requests, go to your .
This is very minor, but there's a contradiction between the usercode provided in the example in section 3.3.3. and the recommendations that are mentioned in the text above it. The text says: And However, the example provided below it goes against these two recommendations, as it contains a special character (a hyphen) rather than just letters and numbers, and it's longer than eight characters in length: I'd suggest either tweaking the wording, or tweaking the example so that the usercode provided in the example is aligned to the recommendations mentioned in the text.
The specification does not require user codes to be unguessable. Section 3.3.3 (Display of a Short User Code) states that user codes have to be unique and should be short-lived, but this does not imply that codes should be unguessable. It seems that Section 13.27 (Exhaustion of Random Value Space) does not apply to user codes, but to values that are clearly random values "such as nonces, tokens, and randomized URIs". If attackers can guess user codes, the same attack described in URL is possible.
Good catch! The intent is for these to be unguessable, so we can add that explicitly.

Related discussion:
text: usercode and the AS supports this mode for the client instance's 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 <del> 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 </del> <ins> web page.  To facilitate usability, this string MUST be case- insensitive, MUST consist of only easily typeable characters (such as letters or numbers).  The string MUST be randomly generated so as to be unguessable by an attacker within the time it is accepted.  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 </ins> eight characters in length. The client instance MUST communicate the "user_code" value to the end
Code change:
clarify that user codes are unguessable, - update user code examples,
To edit notification comments on pull requests, go to your .
This is very minor, but there's a contradiction between the usercode provided in the example in section 3.3.3. and the recommendations that are mentioned in the text above it. The text says: And However, the example provided below it goes against these two recommendations, as it contains a special character (a hyphen) rather than just letters and numbers, and it's longer than eight characters in length: I'd suggest either tweaking the wording, or tweaking the example so that the usercode provided in the example is aligned to the recommendations mentioned in the text.
The specification does not require user codes to be unguessable. Section 3.3.3 (Display of a Short User Code) states that user codes have to be unique and should be short-lived, but this does not imply that codes should be unguessable. It seems that Section 13.27 (Exhaustion of Random Value Space) does not apply to user codes, but to values that are clearly random values "such as nonces, tokens, and randomized URIs". If attackers can guess user codes, the same attack described in URL is possible.
Good catch! The intent is for these to be unguessable, so we can add that explicitly.

Related discussion:
text: 13.27. Several parts of the GNAP process make use of unguessable randomized <del> values, such as nonces, tokens, and randomized URIs.  Since these values are intended to be unique, a sufficiently powerful attacker could make a large number of requests to trigger generation of randomized values in an attempt to exhaust the random number </del> <ins> values, such as nonces, tokens, user codes, and randomized URIs. Since these values are intended to be unique, a sufficiently powerful attacker could make a large number of requests to trigger generation of randomized values in an attempt to exhaust the random number </ins> generation space.  While this attack is particularly applicable to the AS, client software could likewise be targeted by an attacker triggering new grant requests against an AS.
Code change:
NAME Please take a look at this updated text to see if it addresses your concerns.
To edit notification comments on pull requests, go to your .
Thinking about possible extensions to GNAP's interaction modes, I had the impression that the specification could be a bit clearer regarding requirements on such extensions. From reading Section 3.3, my understanding is that all implementations of GNAP, including ones using extensions which define additional interaction finish methods, MUST include a nonce in the grant response (given that the AS wants to use the finish method offered by the client instance): URL However, Section 3.3.5 sounds a bit different, only referring to the two interaction finish methods defined by GNAP core: URL Section 4.2 could be a bit clearer as to what is expected of future extensions to GNAP, it currently says: URL with the two following sections describing the finish methods defined by GNAP core. This is, however, somewhat clearer in Section 4.2.3: I.e., Section 4.2.3 implies that AS must (somehow) provide the client instance with an interaction reference and interaction finish nonce. But it may be helpful to make this more explicit throughout the relevant Sections. There seem to be no requirements for future interaction start methods. It may be helpful to document some minimal requirements, e.g., enough information to identify the grant has to be conveyed to AS via RO in the interaction start (such as the redirect URI in GNAP core).
Thanks NAME for taking the time! The proposed text looks good to me (just one possible typo, I'm not a native speaker, so I'm not 100% sure about that).

Related discussion:
text: This specification defines the following interaction start modes: <ins> All interaction start method definitions MUST provide enough information to uniquely identify the grant request during the interaction.  In the "redirect" and "app" modes, this is done using a unique URI (including its parameters).  In the "user_code" and "user_code_uri" mode, this is done using the value of the user code. </ins> Additional start modes are defined in the IANA-interaction-start- modes.