jiebi/CodeConvo huggingface dataset:
Code change:
ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del> <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.

Related discussion:
text: You could have those be the same AS as well, if Bob's resource server is protected by the same server Alice is using to log in to the client. But they're different kinds of access, and it would make sense to talk about them in a single example scenario to help call out that difference. There's also a weird case from the CIBA work in the OIDF: Alice uses client software to find out who Bob is. The canonical example given here is a call center: Alice needs to verify that the person calling her is actually Bob, and so Alice starts something with the AS that reaches out to Bob to approve the release of identity information about Bob to Alice, in real time.
NAME how does Alice know which AS can release identity information about Bob? I would not make an assumption that one global central AS exists and it has information about the whole Earth's population?
NAME This use case is not assuming a global AS at all (I agree, that's absurd), but it is assuming that Alice and Bob are both working with a known ecosystem. In the case of the call center example, it's the supporting company's AS -- where Alice works and where Bob is a customer. So, Bob needs to have an account there, and so does Alice. Alice's account needs to be authorized to get info about other users (because she's a support tech). Bob's account is a customer account that Alice can fetch information from anyway.
I see, thank you. It indeed looks like another use case where Bob acts as RO but there is no RS or Protected Resource involved.
I've encountered the CIBA use case very recently. Here's a summarised description : the enduser gets in touch (out of band) with the support, so that both are available at the same time the support needs to get read access to some info stored on the enduser's mobile, and uses CIBA to get the enduser's approval returned scopes define what can be accessed through another OIDC client (used by the support agent) there are no RS involved Note : this issue is closed, so either we should reopen it or open a new issue
NAME Agreed, we've drifted off of the topic of the issue as well. I opened up a new issue for discussion of the cross-user CIBA use case specifically:
Code change:
_mandatory_ <del> Reference Claims are components of Reference Values as defined in I-D.ietf-rats-architecture.  [Editor's Note: Definition might become obsolete, if replaced by Reference Values.  Is there a difference between Claims and Values here?  Analogously, why is not named Reference Claims in the RATS arch?] Reference Claims are used to appraise the Claims received from an Attester.  For example, Reference Claims MAY be Reference </del> <ins> Reference Values as defined in I-D.ietf-rats-architecture.  This specific type of Claims is used to appraise Claims incorporated in Evidence.  For example, Reference Values MAY be Reference </ins> Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see <del> Endorsements in I-D.ietf-rats-architecture).  Reference Claims </del> <ins> Endorsements in I-D.ietf-rats-architecture).  Reference Values </ins> typically represent (trusted) Claim sets about an Attester's intended platform operational state.

Related discussion:
text: Based on URL I suggest using Reference Values to keep consistent with the RATS arch.
+1 for "Reference Values"
on it Hi Henk, I've reviewed the reference interaction models I-D recently, I hope the comments below can help improve the draft before the IETF110 draft submission cut-off. Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology. Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). Comment > About "these types of co-located environments", The previous sentences are about the Verifier and Attester don't need to be remote. So "these" is weird here, because here is about the attesting environment and target environment. Section 5 Direct Anonymous Attestation Comment > I think it's better to move this section to the bottom of the draft. DAA doesn't introduce a new information elements, and only augments the scope/definition of Attester Identity and Authentication Secret IDs, describing it after the introduction of all the 3 basic interaction models would be better. Putting DAA in the middle makes me feel the basic interaction models rely upon DAA, but actually it's not. This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters. The existing duties of the Endorser role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections. Comment > Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right? If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn't make sense to me.
Code change:
_mandatory_ <del> Reference Claims are components of Reference Values as defined in I-D.ietf-rats-architecture.  [Editor's Note: Definition might become obsolete, if replaced by Reference Values.  Is there a difference between Claims and Values here?  Analogously, why is not named Reference Claims in the RATS arch?] Reference Claims are used to appraise the Claims received from an Attester.  For example, Reference Claims MAY be Reference </del> <ins> Reference Values as defined in I-D.ietf-rats-architecture.  This specific type of Claims is used to appraise Claims incorporated in Evidence.  For example, Reference Values MAY be Reference </ins> Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see <del> Endorsements in I-D.ietf-rats-architecture).  Reference Claims </del> <ins> Endorsements in I-D.ietf-rats-architecture).  Reference Values </ins> typically represent (trusted) Claim sets about an Attester's intended platform operational state.

Related discussion:
text: Section 5.1 Endorsers Comment > Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section? Comment > This section only describes the Layered Attestation, but the scope of Endorsement is more than what's described here. Endorsement indicates the Attester's various capabilities such as Claims collection and Evidence signing. For other situations than Layered Attestation, the Endorser and Endorsement are also needed. So why only mention Layered Attestation here? I don't see any special relationship between DAA and Layered Attestation. Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these certificates share the semantics of Endorsements, with the following exceptions: Comment > In the first sentence, I suggest saying that "a DAA Issuer takes on the role of an Endorser". o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the Attester randomizes this credential each time that it is used. Comment > How to understand "Evidence is valid"? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)? Comment > When saying "Attester randomizes this credential", how many credentials does an Attester have? 1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier.
Code change:
Using a value for "N" that is small, but at least 1 (for example, 1.25) ensures that variations in round-trip time do not result in <del> under-utilization of the congestion window.  Values of 'N' larger than 1 ultimately result in sending packets as acknowledgments are received rather than when timers fire, provided the congestion window is fully utilized and acknowledgments arrive at regular intervals. </del> <ins> under-utilization of the congestion window. </ins> Practical considerations, such as packetization, scheduling delays, and computational efficiency, can cause a sender to deviate from this

Related discussion:
text: N was introduced in to describe how a sender might pace at a rate that allows it to send a congestion window's worth of data in a period that is shorter than an RTT. This PR clarifies text that goes into unnecessary detail, trying to describe assumptions (the network is spreading the packets out, for example, resulting in an ack clock).
Can we make progress in this one?
Yes, I'm waiting for the design issues to get done before moving on the remaining editorial ones.
I think that has happened now :-)
Nudge
Code change:
The path component of the URI Template MUST start with a slash "/". <del> All template variables MUST be within the path component of the URI. </del> <ins> All template variables MUST be within the path or query components of the URI. </ins> The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables.

Related discussion:
text: The client configuration section says: ... but the examples contain: Which is it?
This was an accident, I suspect it dates back to when the document referred to which contains both path and query. Fixing to mention both path and query via .
Code change:
14. <del> TODO: Registries for protocol parameters, e.g., ciphersuites </del> <ins> This document requests the creation of the following new IANA registries: MLS Ciphersuites All of these registries should be under a heading of "Message Layer Security", and administered under a Specification Required policy RFC8126. 14.1. The "MLS Ciphersuites" registry lists identifiers for suites of cryptographic algorithms defined for use with MLS.  These are two- byte values, so the maximum possible value is 0xFFFF = 65535.  Values in the range 0xF000 - 0xFFFF are reserved for vendor-internal usage. Template: Value: The two-byte identifier for the ciphersuite Name: The name of the ciphersuite Reference: Where this algorithm is defined The initial contents for this registry are as follows: [[ Note to RFC Editor: Please replace "XXXX" above with the number assigned to this RFC. ]] </ins>

Related discussion:
text: This PR begins filling in the IANA Considerations section, starting with a Ciphersuites registry. This addresses the concerns in as discussed at the interim (2019-10), namely by reserving for vendor use chunk of the code points space large enough to be selected at random without huge risk of collision (2^12 values). Depends on
Here's the Weekly Digest for : - - Last week 9 issues were created. Of these, 6 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 13 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 10 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 38 commits.
Code change:
14. <del> TODO: Registries for protocol parameters, e.g., ciphersuites </del> <ins> This document requests the creation of the following new IANA registries: MLS Ciphersuites All of these registries should be under a heading of "Message Layer Security", and administered under a Specification Required policy RFC8126. 14.1. The "MLS Ciphersuites" registry lists identifiers for suites of cryptographic algorithms defined for use with MLS.  These are two- byte values, so the maximum possible value is 0xFFFF = 65535.  Values in the range 0xF000 - 0xFFFF are reserved for vendor-internal usage. Template: Value: The two-byte identifier for the ciphersuite Name: The name of the ciphersuite Reference: Where this algorithm is defined The initial contents for this registry are as follows: [[ Note to RFC Editor: Please replace "XXXX" above with the number assigned to this RFC. ]] </ins>

Related discussion:
text: :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .*
Enable, e.g., P-256 with both AES-GCM and ChaChaPoly Re-use code points from TLS
We should discuss that today
Code change:
any web server that is accessible to the ACME server, even if it is not accessible to the ACME client. <del> The risk of SSRF through this channel is limited by the fact that the attacker can only control the domain of the URL, not the path. Nonetheless, in order to further limit the SSRF risk, ACME server operators should ensure that validation queries can only be sent to servers on the public Internet, and not, say, web services within the server operator's internal network.  Since the attacker could make requests to these public servers himself, he can't gain anything extra through an SSRF attack on ACME aside from a layer of anonymization. </del> <ins> It might seem that the risk of SSRF through this channel is limited by the fact that the attacker can only control the domain of the URL, not the path.  However, if the attacker first sets the domain to one they control, then they can send the server an HTTP redirect (e.g., a 302 response) which will cause the server to query an arbitrary URI. In order to further limit the SSRF risk, ACME server operators should ensure that validation queries can only be sent to servers on the public Internet, and not, say, web services within the server operator's internal network.  Since the attacker could make requests to these public servers himself, he can't gain anything extra through an SSRF attack on ACME aside from a layer of anonymization. </ins> 9.5.

Related discussion:
text: NAME does this look better?
LGTM, though I'd change the attacker from a "he" to a "they" on general principles.
Not a huge fan of the singular "they", but can't be bothered to rewrite around it :)
Yes, this is clearer. Thanks. Saying "will cause the server to query an arbitrary URI" is good. Technically you can even specify a non-HTTP protocol in an HTTP redirect, and this language should cover that too. (Go's net/http used by Boulder only does HTTP and HTTPS I think, but things like libcurl support a slightly insane number of protocols.) I'm not sure if the usages of "URI" vs "URL" in this section are correct, you may want to make them consistent. I never know which one to actually use. This looks good to me.
Code change:
2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710bis.  The CAPPORT architecture expects this URI to indicate the API described in section_api. </del> <ins> Advertisements is described in RFC7710bis.  The captive portal architecture expects this URI to indicate the API described in section_api. </ins> 2.2.2.

Related discussion:
text: This replaces all mentions of capport (other than document slugs) with "captive portal". Note: this change includes the title of the document.
Joel Halpern writes, We should do this.
Or erase all mentions of 'capport'
Code change:
Change Controller: IESG <del> 9.9. </del> <ins> 9.8.2. Type name: application Subtype name: cid-edhoc+cbor-seq </ins> <del> IANA has added the media type "application/edhoc" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters". </del> <ins> Required parameters: N/A </ins> <del> Media Type: application/edhoc </del> <ins> Optional parameters: N/A </ins> <del> Encoding: </del> <ins> Encoding considerations: binary </ins> <del> ID: TBD42 </del> <ins> Security considerations: See Section 7 of this document. </ins> <del> Reference: [[this document]] </del> <ins> Interoperability considerations: N/A Published specification: [[this document]] (this document) Applications that use this media type: To be identified Fragment identifier considerations: N/A Additional information: Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: See "Authors' Addresses" section. Intended usage: COMMON Restrictions on usage: N/A Author: See "Authors' Addresses" section. Change Controller: IESG 9.9. IANA has added the media types "application/edhoc+cbor-seq" and "application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters". </ins> 9.10.

Related discussion:
text: Signed-off-by: David Navarro
NAME NAME and others: Any response to John's comment?
NAME I included John's suggestion in the PR.
Looks good to me. Other opinions?
As specified in section , the payload in some CoAP messages can be an EDHOC message prepended by either a C_x identifier or "true". The draft states: However, the payload is actually a CBOR Sequence as defined by . Thus, we could define and use a new media type "application/edhoc+cbor-seq". Note that the usage of the Content-Format option is optional.
Makes sense to me. NAME NAME others: Comments? Good that you bring up the optionality of Content-Format, we should stress that in this text. The discussion in Hackathon also reminded me about the common-option-compression which NAME presented in the May 12 interim 2021 - how to replace the Uri-Path: "/.well-known/edhoc" with a, say, integer valued CoAP option.
Makes a lot of sense to me, too.
I find this distinction good and the solution consequential, still open for comments.
Code change:
1. Censorship is where an entity in a position of power - such as a <del> government, organization, or individual - supresses communication </del> <ins> government, organization, or individual - suppresses communication </ins> that it considers objectionable, harmful, sensitive, politically incorrect or inconvenient.  (While censors that engage in censorship or establish censorship regimes must do so through legal, military,

Related discussion:
text: s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:
Code change:
Hello, with a different ephemeral key share, as the terminating server will fail to decrypt and verify the ESNI value. <del> 7.2.2. </del> <ins> 7.3.2. </ins> This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys

Related discussion:
text: Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.
Code change:
5.4. <del> frames implicitly create a stream and carry stream data.  The Type field in the frame takes the form 0b00001XXX (or the set of values from 0x08 to 0x0f) to maximize compatibility with QUIC.  However, unlike QUIC, there are only one bit used to determine the fields that are present in the frame: The FIN bit (0x01) indicates that the frame marks the end of the stream.  The final size of the stream is the sum of the length, in bytes, of all data previously sent on this stream and the length of this frame without the length of the Stream ID. </del> <ins> frames implicitly create a stream and carry stream data. The Type field in the frame is either 0x0a or 0x0b.  This uses the same frame types as a QUIC STREAM frame with the OFF bit clear and the LEN bit set.  The FIN bit (0x01) in the frame type indicates that the frame marks the end of the stream in one direction.  Stream data consists of any number of 0x0a frames followed by a terminal 0x0b frame. frames contain the following fields: The stream ID for the stream. Zero or more bytes of data for the stream.  Empty frames MUST NOT be used unless they open or close a stream; an endpoint MAY treat an empty frame that neither starts nor ends a stream as a session error. </ins> 5.5.

Related discussion:
text: The definition was a little loose, so I rewrote it. We only need to use 0x0a and 0x0b, which is lucky and it lets us avoid much of the mess that QUIC has around bits in the type. I've also added definitions for the fields in the frame.