jiebi/CodeConvo huggingface dataset:
Code change:
URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.

Related discussion:
text: multiple access token structure containing one access token. If the AS has split the access token response, the response MUST <del> include the "split" flag set to "true". </del> <ins> include the "split" flag in the "flags" array. </ins> Each access token MAY be bound to different keys with different proofing mechanisms.
Code change:
In the current version, the AS must include an access token. "if the AS includes an access token" sounds like the inclusion of an access token is optional.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 323dd6c268368857c2d9942048f94658b806b8ad Inspect the deploy log: Browse the preview:

Related discussion:
text: REQUIRED.  The URI at which the client instance can make continuation requests.  This URI MAY vary per request, or MAY be <del> stable at the AS if the AS includes an access token.  The client instance MUST use this value exactly as given when making a continue-request. </del> <ins> stable at the AS.  The client instance MUST use this value exactly as given when making a continue-request. </ins> RECOMMENDED.  The amount of time in integer seconds the client instance SHOULD wait after receiving this continuation handle and
Code change:
for
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: c7273a059b212bf18879f131a5a18d9a776a2918 Inspect the deploy log: Browse the preview:
Error Response: Editor's note: I think we will need a more robust error mechanism, and we need to be more clear about what error states are allowed in what circumstances. Additionally, is the "error" parameter exclusive with others in the return?
As a starting point, I would suggest adding these sentences The error code parameter MUST be required and its value SHOULD be limited to ASCII characters. The error code indicates that a request is malformed. The AS MUST return an HTTP 401 (Unauthorized) status code to indicate that it can't identify a client instance (the error code can be ). The AS MUST return an HTTP 401 (Unauthorized) status code to indicate that it can't authenticate a client instance (the error code can be ). The AS MAY uncover additional information about the cause of the error when it can authenticate a client instance (the error code can be , , and so on).
Addressed by , still need error codes for things like token management.
The type of the of the error property in a response is currently ambiguous. In section 3 it is defined as an and in section 3.6 it is defined as a .
NAME thanks for catching that -- looks like both "error" and "errordescription" should be added to the list of parameters. I think the intent might have been for the value of "error" to be an object with "errorcode" and "error_description" fields inside of it though, so it might be better to align things in that direction instead. Do you have thoughts on which is preferable? Interop testing of error conditions is really difficult in practice, so this is a great catch!
Yaron: The AS MUST ignore any unknown extension. Justin: I’m OK with this stance, but it needs to be consistent throughout the protocol, not just at this level. Yaron: we can actually have one policy for an AS that doesn't understand something defined in the RFC (e.g. a token binding method) vs. extensions. Unknown extensions clearly must be ignored, otherwise you cannot deploy extensions incrementally. For RFC elements, this is more nuanced.
With the guidance on extension points from and error codes from and similar, this should now be covered by the current text.

Related discussion:
text: If the AS determines that the request cannot be issued for any reason, it responds to the client instance with an error message. <del> The error code is one of the following, with additional values available in IANA: </del> [[ See issue #79 [15] ]] 3.7.
Code change:
Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Related discussion:
text: Any keys presented by the client instance to the AS or RS MUST be validated as part of the request in which they are presented.  The <del> type of binding used is indicated by the proof parameter of the key object in key-format.  Values defined by this specification are as follows: </del> <ins> type of binding used is indicated by the "proof" parameter of the key object in key-format.  This parameter is formally specified by an object with at least the following member: Individual methods MAY define additional parameters as members in this object. Values for the "method" defined by this specification are as follows: </ins> Additional proofing methods are defined by IANA. <ins> For example, the "httpsig" method can be specified with its parameters as: If additional parameters are not required or used for a specific method, the method MAY be passed as a string instead of an object. For example, the "mtls" method with no additional parameters could be sent by the client instance as: The AS would map this to the equivalent expanded form as follows: </ins> All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would change the nature of the request, to allow for secure validation of
Code change:
Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Related discussion:
text: 7.3.1. <del> This method is indicated by "httpsig" in the "proof" field.  The signer creates an HTTP Message Signature as described in I-D.ietf- httpbis-message-signatures. </del> <ins> This method is indicated by the method value "httpsig".  The signer creates an HTTP Message Signature as described in I-D.ietf-httpbis- message-signatures.  This method defines the following parameters: </ins> The covered components of the signature MUST include the following:
Code change:
Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Related discussion:
text: 7.3.2. <del> This method is indicated by "mtls" in the "proof" field.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </del> <ins> This method is indicated by the method value "mtls".  This method defines no additional parameters.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </ins> In this example, the certificate is communicated to the application through the "Client-Cert" header from a TLS reverse proxy, leading to
Code change:
Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Related discussion:
text: 7.3.3. <del> This method is indicated by "jwsd" in the "proof" field.  A JWS RFC7515 object is created as follows: </del> <ins> This method is indicated by the method value "jwsd".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </ins> To protect the request, the JOSE header of the signature contains the following claims:
Code change:
Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.

Related discussion:
text: 7.3.4. <del> This method is indicated by "jws" in the "proof" field.  A JWS RFC7515 object is created as follows: </del> <ins> This method is indicated by the method value "jws".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </ins> To protect the request, the JWS header contains the following claims.
Code change:
Deploy Preview for gnap-resource-servers-editors-draft ready! Built Explore the source changes: 611af53328d71bac58f517702c5775a9c514d88d Inspect the deploy log: Browse the preview:

Related discussion:
text: 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.
Code change:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Related discussion:
text: secure delegation.  The zone signing and secure delegation may be performed either by the Homenet Naming Authority or by the Outsourcing Infrastructure. sec-dnssec-deplyment discusses these two <del> alternatives. sec-views discusses the consequences of publishing multiple representations of the same zone also commonly designated as views.  This section provides guidance to limit the risks associated with multiple views.  sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </del> <ins> alternatives. sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </ins> Finally, sec-privacy and sec-security respectively discuss privacy and security considerations when outsourcing the Homenet Zone. <ins> The Homenet Zone is expected to host public information only.  It is not the scope of this DNS service to define local home network boundaries.  Instead, local scope information is expected to be provided to the home network using local scope naming services. mDNS RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently mDNS is limited to a single link network.  However, future protocols are expected to leverage this constraint as pointed out in RFC7558. </ins> 3. Customer Premises Equipment: (CPE) is a router providing
Code change:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Related discussion:
text: Server.  On the other hand, if the HNA signs the Homenet Zone itself, the zone would be collected by the Synchronization Server and directly transferred to the Public Authoritative Server(s).  These <del> policies are discussed and detailed in sec-dnssec-deplyment and sec- views. </del> <ins> policies are discussed and detailed in sec-dnssec-deplyment. </ins> 4.2.
Code change:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Related discussion:
text: As depicted in fig-naming-arch and fig-auth-servers, the Public Homenet Zone is hosted on the Public Authoritative Server(s), whereas <del> the Homenet Zone is hosted on the HNA.  Motivations for keeping these two zones identical are detailed in sec-views, and this section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </del> <ins> the Homenet Zone is hosted on the HNA.  This section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </ins> In that case, the Homenet Zone should configure its Name Server RRset (NS) and Start of Authority (SOA) with the values associated with the
Code change:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Related discussion:
text: Reasons for signing the zone by the HNA are: <del> 1) Keeping the Homenet Zone and the Public Homenet Zone equal to </del> <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely optimize DNS resolution.  As the Public Zone is signed with DNSSEC, RRsets are authenticated, and thus DNS responses can be validated even though they are not provided by the
Code change:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Related discussion:
text: otherwise a resolution with the Public Authoritative Server(s) would be performed. <del> 2) Keeping the Homenet Zone and the Public Homenet Zone equal to </del> <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely address the connectivity disruption independence detailed in RFC7368 section 4.4.1 and 3.7.5.  As local lookups are possible in case of network disruption, communications within the home
Code change:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Related discussion:
text: lookup would provide DNS as opposed to DNSSEC responses provided by the Public Authoritative Server(s). <del> 3) Keeping the Homenet Zone and the Public Homenet Zone equal to guarantee coherence between DNS responses.  Using a unique zone is one way to guarantee uniqueness of the responses among servers and places.  Issues generated by different views are discussed in more details in sec-views. 4) Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </del> <ins> Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </ins> Reasons for signing the zone by the Outsourcing Infrastructure are:
Code change:
When comparing the term 'Appraisal Policy for Evidence' and 'Appraisal Policy for Attestation Result', they are both saying 'evaluates the validity of information about an Attester'. This makes me feel Verifier and Relying Party are doing the same things and they are redundant. I think it's more appropriate to say that the Relying Party evaluates the evaluation results generated by the Verifiers.

Related discussion:
text: This document uses the following terms: Appraisal Policy for Evidence: A set of rules that direct how a <del> verifier evaluates the validity of information about an Attester. </del> <ins> Verifier evaluates the validity of information about an Attester. </ins> Compare /security policy/ in [RFC4949]. Appraisal Policy for Attestation Result: A set of rules that <del> direct how a Relying Party evaluates the validity of information about an Attester.  Compare /security policy/ in [RFC4949]. </del> <ins> direct how a Relying Party uses the evaluation results about an Attester generated by the Verifiers.  Compare /security policy/ in [RFC4949]. </ins> Attestation Result: The evaluation results generated by a Verifier, typically including information about an Attester, where
Code change:
Added clarifying text -
" including roots of trust" from .
We should add the sentence "Normally, claims are not self-asserted by a layer or root of trust." in the section describing layered attester / layering. around line 1120?
I'd not object that. I'd be okay with "Normally, claims are not self-asserted by a root of trust."

Related discussion:
text: transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be <del> collected from or about each layer.  The corresponding claims can be </del> <ins> collected from or about each layer.  The corresponding Claims can be </ins> structured in a nested fashion that reflects the nesting of the <del> Attester's layers. </del> <ins> Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. Claims about a root of trust typically are asserted by Endorsers. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system
Code change:
rebased.
` The first sentence seems to say ‘you can do whatever you want’, but the second seems to say “you should sign the messages” This doesn’t seem to be about integrity; it says Evidence must be confidential. Is that actually a requirement?
I don't see where it says RATS messages have to be confidential. 'end-to-end' means between RATS roles. Which can be achieved at different nesting levels; where nesting is interpreted to mean nesting in the message (data) layers. Summary - I don't see a problem with the proposed text.
I am inclined to agree with Ned here, but we could change the first line, while we're at it. The reuse of the word "protected" used in the 1st sentence in the 2nd sentence now might make it more clear that this message protection can happen on many layers.
Ok but this PR merges into the branch instead of master. Recommend rebasing on master so that order of merge doesn't matter.

Related discussion:
text: Relying Party or for a Verifier, then integrity of the process is compromised. <del> The security of conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding format.  This architecture expects attestation messages (i.e., Evidence, Attestation Results, Endorsements, Reference Values, and Policies) are end-to-end protected based on the role interaction </del> <ins> The security protecting conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding format.  This architecture expects attestation messages (i.e., Evidence, Attestation Results, Endorsements, Reference Values, and Policies) are end-to-end protected based on the role interaction </ins> context.  For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not