Question: header field with the 'N' bit set, it MUST use a literal representation to forward this header field.  This bit is intended for protecting header field values that are not to be put at risk by <del> compressing them (see Section 7.1 of RFC7541 for more details). </del> <ins> compressing them (see security-considerations for more details). </ins> The fourth ("S") bit indicates whether the reference is to the static <del> or dynamic table.  The 4-bit prefix integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. </del> <ins> or dynamic table.  The 4-bit prefix integer (see prefixed-integers) that follows is used to locate the table entry for the header name. When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. Only the header field name is taken from the dynamic table entry; the header field value is encoded as an 8-bit prefix string literal (see string-literals). </ins> 4.5.5. <del> If the name entry is in the dynamic table with an absolute index greater than or equal to the Base, the representation starts with the '0000' four-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference.  Finally, the header field name is represented using the post-base index of that entry (see post-base) encoded as an integer with a 3-bit prefix. </del> <ins> A literal header field with post-base name reference represents a header field where the name matches the header field name of a dynamic table entry with an absolute index greater than or equal to the Base. This representation starts with the '0000' four-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference. This is followed by a post-base index of the dynamic table entry (see post-base) encoded as an integer with a 3-bit prefix (see prefixed- integers). Only the header field name is taken from the dynamic table entry; the header field value is encoded as an 8-bit prefix string literal (see string-literals). </ins> 4.5.6. <del> An addition to the header table where both the header field name and the header field value are represented as string literals (see primitives) starts with the '001' three-bit pattern. The fourth bit, 'N', indicates whether an intermediary is permitted to add this header to the dynamic header table on subsequent hops. When the 'N' bit is set, the encoded header MUST always be encoded with a literal representation.  In particular, when a peer sends a header field that it received represented as a literal header field with the 'N' bit set, it MUST use a literal representation to forward this header field.  This bit is intended for protecting header field values that are not to be put at risk by compressing them (see Section 7.1 of RFC7541 for more details). The name is represented as a 4-bit prefix string literal, while the value is represented as an 8-bit prefix string literal. </del> <ins> The literal header field without name reference representation encodes a header field name and header field value as string literals. This representation begins with the '001' three-bit pattern.  The fourth bit is the 'N' bit as described in literal-name-reference. The name follows, represented as a 4-bit prefix string literal, then the value, represented as an 8-bit prefix string literal (see string- literals). </ins> 5.


Question: ServerConfiguration format. The semantics of this message are to establish a shared state between <del> the client and server for use with the "known_configuration" extension with the key specified in key and with the handshake </del> <ins> the client and server for use with the "early_data" extension with the key specified in "static_key_share" and with the handshake </ins> parameters negotiated by this handshake. When the ServerConfiguration message is sent, the server MUST also send a Certificate message and a CertificateVerify message, even if <del> the "known_configuration" extension was used for this handshake, thus </del> <ins> the "early_data" extension was used for this handshake, thus </ins> requiring a signature over the configuration before it can be used by the client.  Clients MUST NOT rely on the ServerConfiguration message until successfully receiving and processing the server's Certificate,

Cleaned up references to knownconfiguration extension (merged into earlydata in draft-08)


Question: If the answer contains valid bundle groups, discard any ICE components for the "m=" sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these "m=" <del> sections accordingly, as described in RFC8843. </del> <ins> sections accordingly, as described in I-D.ietf-mmusic-rfc8843-bis. </ins> If the description is of type "answer" and there are still remaining candidates in the ICE candidate pool, discard them.

and
To resolve WGLC comments: URL it was agreed to incorporate a reference to this text in 8843bis: URL That text ended up in s7.6.
When draft-8843bis is given an RFC number, this draft should reference the new RFC. Hi, Eventhough I would not like to make more changes than necessary, I am fine with "3PCC Considerations". However, your suggested text is very difficult to understand in some places, so let me give it a try. (The first paragraph is generic, the second SIP specific, and the third BUNDLE specific.) 3PCC Considerations In some 3PCC scenarios a new session will be established between an endpoint that is currently part of an ongoing session and an endpoint that is currently not part of an ongoing session. The endpoint that is part of a session will generate a subsequent offer that will be forwarded to the other endpoint by a 3PCC controller. The endpoint that is not part of a session will process the offer as an initial offer. The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. If the UAS is a part of an ongoing session, it will include a subsequent offer in the 200 OK response. The offer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA). If the UA is not part of an ongoing session, it will process the offer as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed using different rules than subsequent BUNDLE offers, and it cannot be assumed that a UA is able to correctly process a subsequent offer as an initial offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer, following the procedures in (Section 7.2), before it forwards the offer to a UA.


Question: If the answer contains valid bundle groups, discard any ICE components for the "m=" sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these "m=" <del> sections accordingly, as described in RFC8843. </del> <ins> sections accordingly, as described in I-D.ietf-mmusic-rfc8843-bis. </ins> If the description is of type "answer" and there are still remaining candidates in the ICE candidate pool, discard them.

In the rewritten offer the 3PCC controller will set the port value to zero (and include an SDP 'bundle-only' attribute) for each "m=" section within the BUNDLE group, excluding the offerer-tagged "m=" section. __ From: Roman Shpount Sent: Tuesday, November 2, 2021 6:33 PM To: Christer Holmberg Cc: Justin Uberti ; Justin Uberti ; RTCWeb IETF Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-URL How about we replace the SIP Considerations with: 3PCC Considerations In some 3PCC scenarios, an offer generated during an ongoing session, i.e., a subsequent offer, will be used by a 3PCC controller to establish a new session and forwarded as an initial offer to another endpoint that is currently not part of a session. For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session, it will include a subsequent offer in the 200 OK response. The offer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA) as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed using different rules than subsequent BUNDLE offers. It cannot be assumed that a subsequent offer is a valid initial offer and that the endpoint that expects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer before it is used to establish a new session. To make the subsequent offer a valid initial offer, 3PCC will need to modify all the non-tagged m= lines to include the bundle-only attribute and set the m= line port to zero.


Question: If the answer contains valid bundle groups, discard any ICE components for the "m=" sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these "m=" <del> sections accordingly, as described in RFC8843. </del> <ins> sections accordingly, as described in I-D.ietf-mmusic-rfc8843-bis. </ins> If the description is of type "answer" and there are still remaining candidates in the ICE candidate pool, discard them.

_ Roman Shpount Christer Holmberg > wrote: Hi, What about something like this: OLD: “The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP Offer in the associated 200 OK response. This is typically used for 3rd Party Call Control (3PCC) scenarios. >From a BUNDLE perspective, such SDP Offer SHOULD be generated using the procedures defined in Section 7.2.” NEW: “The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. This is typically used for 3rd Party Call Control (3PCC) scenarios. In some 3PCC scenarios the UAS will be part of an ongoing session, and will therefore include a subsequent offer in the 200 OK responses. The offer will be received by a 3PCC controller (UAC) and then forwarded as an initial offer to another User Agent (UA) that is currently not part of a session. When the BUNDLE mechanism is used, as an initial BUNDLE offer look different than a subsequent BUNDLE offer, it cannot be assumed that a UA that expects an initial offer will be able to properly process a subsequent offer.


Question: If the answer contains valid bundle groups, discard any ICE components for the "m=" sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these "m=" <del> sections accordingly, as described in RFC8843. </del> <ins> sections accordingly, as described in I-D.ietf-mmusic-rfc8843-bis. </ins> If the description is of type "answer" and there are still remaining candidates in the ICE candidate pool, discard them.

Therefore, the 3PCC controller needs to act as a Back-To-Back User Agent (B2BUA), and when it receives the subsequent offer it needs to rewrite it into an initial offer before it is forwarded to such UA.” Regards, Christer From: Roman Shpount > Sent: tiistai 2. marraskuuta 2021 10.41 To: Justin Uberti > Cc: Christer Holmberg >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-URL The PROBLEM is that we have two endpoints, where one sends a subsequent offer, and the other one expects an initial offer. What do you normally do when you have that kind of problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the 3PCC controller. So, my suggestion would be to remove the SHOULD text from 8843bis, and simply add a note somewhere (in 8843bis and/or 8829bis) which describes the issue and says that the 3GPP controller needs to modify the offer accordingly. Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyway then maybe adding a=bundle-only isn't the end of the world. I am not opposed to this idea. 3PCC typically knows that the subsequent offer is going to be used as initial, and should be able to rewrite the offer to make it valid. We can change SIP Considerations section in 8843bis (URL), remove the SHOULD, and specify that 3PCC controller should fix the offer. We can then reference this note from 8829bis or restate the same guidance. Roman Shpount
Not seeing any objections for a month then once -02 is submitted we will progress this towards our AD. spt


Question: of the first ClientHelloInner via the derived ech_hrr_key by modifying HPKE setup as follows: <del> Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. </del> <ins> The "info" parameter to SetupPSKS is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig.  Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. </ins> Client-facing servers perform the corresponding process when decrypting second ClientHelloInner messages.  In particular, upon

The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.


Question: This property specifies that a message should be sent in such a way that the transport protocol ensures all data is received on the other side without corruption.  Changing the 'Reliable Data Transfer' <del> property on Messages is only possible if the transport protocol supports partial reliability (see prop-partially-reliable). Therefore, for protocols that always transfer data reliably, this property is always true and for protocols that always transfer data unreliably, this property is always false.  Changing it may generate an error. </del> <ins> property on Messages is only possible if the Connection supports reliability.  When this is not the case, changing it will generate an error. </ins> 7.3.8.

I didn't like something about reliability (let's not throw an error when we can't be UNreliable, only when we can't be reliable). I updated the text on ordering a bit, to say that the Property is ignored for the first Message on a Connection, and rephrased it slightly to talk about the receiver-side transport system and the receiving application - before, the text might have talked about a sender-side behavior. I added a TODO DISCUSS comment about per-message Niceness.
Fine with me, maybe fix minor knitThanks, all good now I think.


Question: Specific processing MUST also be applied for the following attribute lines: <del> If present, a single "a=ice-lite" line is parsed as specified in RFC5245, Section 15.3, and a value indicating the presence of ice- lite is stored. </del> If present, a single "a=ice-ufrag" line is parsed as specified in RFC5245, Section 15.4, and the ufrag value is stored.

LGTM
http://rtcweb-URL mentions its use at media level; this should be clarified.


Question: process can be represented and performed by Internet protocols with no out-of-band human intervention. <del> When an operator deploys a current HTTPS server, it generally prompts him to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </del> <ins> When deploying a current HTTPS server, an operator generally gets a prompt to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </ins> The ACME client prompts the operator for the intended domain name(s) that the web server is to stand for.

Avoid changing the "him" in the MitM paragraph, because of the inherent notion of a Man in the Middle, which is a larger discussion.
LGTM. Thanks for the elegant fix.


Question: 16.3. This registry lists identifiers for types of credentials that can be <del> used for authentication in the MLS protocol.  The extension type field is two bytes wide, so valid extension type values are in the </del> <ins> used for authentication in the MLS protocol.  The credential type field is two bytes wide, so valid credential type values are in the </ins> range 0x0000 to 0xffff. Template:

I noticed a bunch of typos in the "IANA Considerations" section: the "ciphersuites" and "credentials" were probably copy-pasted from the "extension" one, and some parts were not changed correctly. This PR fixes these typos.
Discussed 20210526 Interim: editorial will be taken up by editors.
Thanks!


Question: entity that receives an Initial packet from a client can recover the keys that will allow them to both read the contents of the packet and generate Initial packets that will be successfully authenticated at <del> either endpoint. </del> <ins> either endpoint.  The AEAD also protects Initial packets against accidental modification. </ins> All other packets are protected with keys derived from the cryptographic handshake.  The cryptographic handshake ensures that

The description neglected to mention this. Obviously, the confidentiality protection (specifically, the lack thereof) is the part that needs to be highlighted, but we shouldn't neglect the other purpose of using an AEAD here.


Question: transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below. <ins> Note that while setDirection sets the direction attribute of the transceiver immediately (sec.transceiver-direction), this attribute does not immediately affect whether the transceiver's RtpSender will send or its RtpReceiver will receive.  The direction in effect is represented by the currentDirection attribute, which is only updated when an answer is applied. </ins> 4.2.4. The direction method returns the last value passed into setDirection.

Fixes issue .
Section 4.2.3: The setDirection method sets the direction of a transceiver, which affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer. [BA] "sets the direction of a transceiver" is a bit confusing because setDirection() doesn't immediately change whether an RtpSender can send or an RtpReceiver can receive. Since setDirection does immediately change the value of the transceiver.direction attribute you might say "sets the transceiver.direction attribute" instead. Also, an application may want to determine the current direction (e.g. whether an RtpSender can send or an RtpReceiver can receive) as opposed to the pending direction (provided by transceiver.direction). Taylor agreed to create a WebRTC 1.0 PR to add the concept of current direction (e.g. by adding a currentDirection attribute). It would therefore be useful to add some text to Section 4.2.3 explaining the distinction. For example: "Note that while setDirection sets the transceiver.direction attribute immediately, this pending direction does not immediately affect whether an RtpSender will send or RtpReceiver will receive. After calls to setLocal/setRemoteDescription, the direction currently in effect is represented by transceiver.currentDirection (the attribute Taylor will be defining)."
As for naming: which of these makes the most sense? "direction"/"currentDirection" "pendingDirection"/"currentDirection" "preferredDirection"/"currentDirection" "preferredDirection"/"negotiatedDirection" I like "preferredDirection" (or something of that nature); "pending" is a bit of a misnomer here because it's possible the set direction may never end up negotiated.
NAME My personal preference would be "direction"/"currentDirection". While "pendingDirection" might be more accurate than "direction", I'm a bit scared of all the spec changes that might be result from changing the attribute name.
Agree with NAME
LGTM (direction + currentDirection).
NAME can this now be closed?
I don't think Bernard's concern was addressed, which is that "sets the direction of a transceiver" is too ambiguous. Now that we have a "currentDirection" to reference, I'll add some clarifying text like he suggested.
Resolved by .


Question: blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the <del> Architecture document I-D.ietf-privacypass-architecture. </del> <ins> Architecture document ARCHITECTURE. </ins> Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This

There are two cases where the term seems to be used with importance. I suspect that the Internet isn't actually that important in the context / scope of this protocol document, especially since the architecture document doesn't mention it.
Yep, good catch. It's not.
Is there a more polite way to phrase this disclaimer?
This follows RFC 2119 (URL) and RFC 8174 linked from terminology where these are reserved phrases with specific meaning in IETF specifications and documents. Though technically these should probably be "SHOULD NOT" and "SHALL NOT" to be in line with the RFC terms.
What requirements are being defined in the quoted text though? Is it simply a statement of fact like "this document doesn't cover architectural stuff" or is it "implementations of the issuance protocol SHOULD account for considerations related to operations and privacy described in the architecture document"?
NAME this is just a statement of fact -- we don't need to shout it =)


Question: If the m= section proto value indicates use of RTP: <del> If there is no RtpTransceiver associated with this m= section (which will only happen when applying an offer), find one and associate it with this m= section according to the following steps: </del> <ins> If there is no RtpTransceiver associated with this m= section, find one and associate it with this m= section according to the following steps.  Note that this situation will only occur when applying an offer. </ins> Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section

Fixes URL
See comment in
Alright, try this version
Section 5.8 contains the sentence: "If there is no RtpTransceiver associated with this m= section (which will only happen when applying an offer)..." -- it is grammatically ambiguous whether this says that the absence of an RtpTranceiver can only happen with an offer, or if the presence of an RtpTranceiver can only happen with an offer. Suggest rephrasing as: "If applying an offer and there is no RtpTransceiver associated with this m= section, find one..."
NAME can you take a look at this?
I'm not sold on this approach, since it then invites the question, what should one do if this condition happens when applying an answer? My suggestion would be to still call this out explicitly, but try to avoid the ambiguity noted above by changing the parenthetical to its own sentence at the end of the paragraph, e.g. "Note that this situation will only occur when applying an offer."
I changed it to that.
LGTM


Question: 2.3.2. <ins> 2.3.2.1. The y-coordinate of the other endpoint's Ed25519 public key is decoded as specified in Section 5.1.3 of RFC8032.  The Curve25519 u-coordinate is recovered as u = (1 + y) / (1 - y) (mod p) following the map in Section 4.1 of RFC7748.  Note that the mapping is not defined for y = 1, and that y = -1 maps to u = 0 which corresponds to the neutral group element and thus will result in a degenerate shared secret.  Therefore implementations MUST abort if the y-coordinate of the other endpoint's Ed25519 public key is 1 or -1 (mod p). The private signing key byte strings (= the lower 32 bytes used for generating the public key, see step 1 of Section 5.1.5 of RFC8032) are decoded the same way for signing in Ed25519 and scalar multiplication in X25519.  Hence, to compute the shared secret the endpoint applies the X25519 function to the Ed25519 private signing key byte string and the encoded u-coordinate byte string as specified in Section 5 of RFC7748. 2.3.2.2. The y-coordinate of the other endpoint's Ed448 public key is decoded as specified in Section 5.2.3. of RFC8032.  The Curve448 u-coordinate is recovered as u = y^2 * (d * y^2 - 1) / (y^2 - 1) (mod p) following the map from "edwards448" in Section 4.2 of RFC7748, and also using the relation x^2 = (y^2 - 1)/(d * y^2 - 1) from the curve equation. Note that the mapping is not defined for y = 1 or -1.  Therefore implementations MUST abort if the y-coordinate of the peer endpoint's Ed448 public key is 1 or -1 (mod p). The private signing key byte strings (= the lower 57 bytes used for generating the public key, see step 1 of Section 5.2.5 of RFC8032) are decoded the same way for signing in Ed448 and scalar multiplication in X448.  Hence, to compute the shared secret the endpoint applies the X448 function to the Ed448 private signing key byte string and the encoded u-coordinate byte string as specified in Section 5 of RFC7748. 2.3.3. </ins> When using any of its Pairwise Sender Keys, a sender endpoint including the 'Partial IV' parameter in the protected message MUST use the current fresh value of the Sender Sequence Number from its

NAME Good point about being more explicit. I actually think is valuable to reference an existing encoding of public keys providing also key type and curve, like CREDX in URL Also, there is a discussion about format for public keys in COSE, which if it is specified probably will be referenced by EDHOC instead of CREDX. I would be good if there is a common format used in all these instances. For the time being I propose that we reference CRED_X with empty text string subject name, and keep track of the COSE activity.
We should consider replace the NIST reference with SECG [1] to harmonize with EDHOC [2]. [1] URL [2] URL (edit) ... but the commits in [3] mainly refers to the NIST spec. so I propose we keep it as is for the time being. [2] URL
It looks good to me; we can give more details on one point. For the two HKDF invocations in Section 2.3.1, we can define more explicitly how the public keys are expressed when concatenated to form IKM-Sender and IKM-Recipient. Given a public key, that can simply be: For OKP signature keys, the compressed 'x' coordinate, i.e. what would be expressed in the key parameter -2 of a corresponding COSE Key. For EC2 signature keys, the 'x' coordinate followed by the 'y' coordinate in this order, i.e. what would be expressed in the key parameters -2 and -3 of a corresponding COSE Key. This should be sufficient, i.e. it shouldn't be needed to have a more structured encoding of public keys providing also key type and curve, e.g. like done for CRED_X in URL


Question: "lazy" version of this operation, where only the leaf changes and intermediate nodes are blanked out. <del> The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal.  The "path" field MUST also be populated if the Commit covers no proposals at all (i.e., if the proposals vector is empty).  The "path" field MAY be omitted if the Commit covers only Add proposals.  In pseudocode, the logic for validating a Commit is as follows: </del> <ins> By default, the "path" field of a Commit MUST be populated.  The "path" field MAY be omitted if (a) it covers at least one proposal and (b) none proposals covered by the Commit are of "path required" types.  A proposal type requires a path if it cannot change the group membership in a way that requires the forward secrecy and post- compromise security guarantees that an UpdatePath provides.  The only proposal types defined in this document that do not require a path are: "add" "psk" "app_ack" "reinit" New proposal types MUST state whether they require a path.  If any instance of a proposal type requires a path, then the proposal type requires a path.  This attribute of a proposal type is reflected in the "Path Required" field of the proposal type registry defined in mls-proposal-types. Update and Remove proposals are the clearest examples of proposals that require a path.  An UpdatePath is required to evict the removed member or the old appearance of the updated member. In pseudocode, the logic for validating the "path" field of a Commit is as follows: </ins> To summarize, a Commit can have three different configurations, with different uses:

This PR introduces a notion of a proposal type being "path safe", in the sense that it is safe for the path to be omitted. (Better phrasing welcome!) The field is required default, and allowed to be omitted only if all the proposals in the Commit are path-safe.
Thanks for taking care of this fix! One suggestion: Instead of having a global list of which types are path safe and which ones aren't, we could make it a property of the proposal. Maybe something like this: Regarding the name, the only thing I can think of is that we could invert the property and call it : In fact, I think I'd be slightly in favor of the latter proposal.
Discussion on virtual interim: OK to keep using type TODO(NAME "path safe" -> "path required" Otherwise clear to merge
The authoritative definition (in Section ) of when to include a is not the same as the summary below. For example, if an implementation adds a custom proposal type, according to the summary, a path is required, whereas according to the definition above it, no path is required. Ultimately, it depends on the nature of the proposal and the desired security guarantees if a path is required. However, I think the safer option is to require a path by default and maybe leave it to the definition of the respective custom proposal to explicitly specify if a path is not required.


Question: The primary function of a connection ID is to ensure that changes in addressing at lower protocol layers (UDP, IP, and below) don't cause <del> packets for a QUIC connection to be delivered to the wrong endpoint. The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint.  At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for. </del> <ins> packets for a QUIC connection to be delivered to the wrong QUIC endpoint.  The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint.  At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for. </ins> The connection ID is chosen by each endpoint using version-specific methods.  Packets for the same QUIC connection might use different

Editorial NiTs when reviewing the invariant text. These NiTs address readability issues, and do not intend to change the meaning of the text.
Is there an associated issue?
Thanks Gorry, these are all quite helpful. 1) I understand the acronyms DCID and SCID, but these aren't really expanded on first use in sect 5.1. 2) There's mention of "the high bit", but there doesn't seem to be any statement of bit order saying. Is it worth declaring network byte/bit order earlier in section 4? This also clarifies the placement of fields within a byte, which was basically assumed knowledge otherwise. 3) Personally, I don't think: "The length of the Destination Connection ID is not specified" is a great choice of words. Surely, this needs to be specified somewhere for a protocol instance to use it? This reads better as something like: The length of the Destination Connection ID is not encoded in packets with a short header and is not constrained by this specification. 4) The brackets here seem to point to connection IDs in general, not the DCID "(see Section 5.3)". Is it worth writing that as "Connection IDs are described in Section 5", rather than use brackets? The same is true for versions. 5) In section 5.3: "the wrong endpoint" is taken as the wrong transport endpoint, but some of our IP and subIP colleagues would use the term endpoint for other uses, so one insertion of "transport" would perhaps help? 6) In the appendix A, this: "QUIC forbids acknowledgments of packets" - still has me wondering what is actually intended to be understood, because the list of bullets is not guarenteed ... : /The last packet before a long period of quiescence might be assumed to contain an acknowledgment (it should be assumed that QUIC could allow acknowledgments of packets that only contain ACK frames)/ I'm not sure what to say here I think the combination of not... forbids threw me off the meaning. Changes proposed in
Thanks for changing SCID/DCID to "Source Connection ID" and "Destination Connection ID", that seems like a good change.


Question: protocols are not incorrectly swapped, Transport Services systems SHOULD only automatically generate equivalent Protocol Stacks when the transport security protocols within the stacks are identical. <del> Specifically, a Transport System would consider protocols </del> <ins> Specifically, a Transport Services system would consider protocols </ins> identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport Protocol Stacks are considered equivalent, whereas TLS

Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!


Question: This protocol MUST be used with https scheme URI RFC7230. <del> This protocol MUST use HTTP/2 RFC7540 or its successors in order to satisfy the security requirements of DNS over HTTPS.  Further, the messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression, all of which are supported by HTTP/2 RFC7540 or its successors. </del> <ins> 7.1. The minimum version of HTTP used by DOH SHOULD be HTTP/2 RFC7540. The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, parallelism, priority, and header compression to acheive similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but would result in very poor performance for many uses cases. </ins> 8.

NAME I'm ok with you merging this and closing 11 if you're ok with it.
I think that it is fine - or more precisely, invaluable - to explain what the semantics of server push are. But you don't actually require HTTP/2 for this protocol to work. The only thing that requiring HTTP/2 gets you is tighter constraints on TLS usage. You can get those same constraints with some deployment recommendations. I would support strong recommendations that said HTTP/2 is useful for its multiplexing as well as similarly strong advice about following the advice in RFC 7525. Those are both good practice.
fairly clear feedback from singapore to change this to an endorsement (SHOULD) with better explanatory text focusing on performance and scale.
What are the drawbacks of HTTP/2? Less readily available libraries? more complex protocol? Potential difficulties in integrating with current fronting stacks that may not be HTTP/2 ready? On one hand, I feel like it may be easier to just enforce 1 stack for now rather than having to support multiple flavor of client/server protocols. A suboptimal HTTP/2 implementation may just be similar to HTTP/1 but at least we can try to move forward toward multiplexing. Making HTTP/2 a should may just leave us in limbo in HTTP/1 land.
NAME the singapore meeting is available here URL .. goto the 12 minute mark to review the discussion (wrt your question about drawbacks).
Text is in URL
Last PR accepted. I suspect there will be a bit more wordsmithing, but this should cover the main issue well.
thanks, I was in the room, but my notes were sparse and some of the cons I remembered of were more inconvenience to me than blockers. What I am not getting from the current spec, and which I believe NAME touched on in URL, is that it is unclear whether or not a minimum HTTP version must be supported. Based on URL , do we consider that by supporting HTTP/1.1 we get HTTP/1.0 for free and consider 0.9 not an option? Wouldn't not mandating a required version prevent client/server from having a known version to use? Can we make this clearer maybe?
The decision was to rely only on HTTP semantics and not versions. So any HTTP implementation that is acceptable to its peer can be used.


Question: 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:

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:


Question: 12.34. <ins> GNAP allows the RO to be contacted by the AS asynchronously, outside the regular flow of the protocol.  This allows for some advanced use cases, such as cross-user authentication or information release, but such advanced use cases have some distinct issues that implementors need to be fully aware of before using these features. First, in many applications, the return of a subject information to the client instance could indicate to the client instance that the end-user is the party represented by that information, functionally allowing the end-user to authenticate to the client application. While the details of a fully functional authentication protocol are outside the scope of GNAP, it is a common exercise for a client instance to be requesting information about the end user.  This is facilitated by the several interaction-start defined in GNAP that allow the end user to begin interaction directly with the AS. However, when the subject of the information is intentionally not the end-user, the client application will need some way to differentiate between requests for authentication of the end user and requests for information about a different user.  Confusing these states could lead to an attacker having their account associated with a privileged user.  Client instances can mitigate this by having distinct code paths for primary end user authentication and requesting subject information about secondary users, such as in a call center.  In such use cases, the client software used by the resource owner (the caller) and the end-user (the agent) are generally distinct, allowing the AS to differentiate between the agent's corporate device making the request and the caller's personal device approving the request. Second, RO's interacting asynchronously do not usually have the same context as an end user in an application attempting to perform the task needing authorization.  As such, the asynchronous requests for authorization coming to the RO from the AS might have very little to do with what the RO is doing at the time.  This situation can consequently lead to authorization fatigue on the part of the RO, where any incoming authorization request is quickly approved and dispatched without the RO making a proper verification of the request.  An attacker can exploit this fatigue and get the RO to authorize the attacker's system for access.  To mitigate this, AS systems deploying asynchronous authorization should only prompt the RO when the RO is expecting such a request, and significant user experience engineering efforts need to be employed to ensure the RO can clearly make the appropriate security decision.  Furthermore, audit capability, and the ability to undo access decisions that may be ongoing, is particularly important in the asynchronous case. </ins> An attacker may aim to gain access to confidential or sensitive resources.  The measures for hardening and monitoring resource server systems (beyond protection with access tokens) is out of the scope of

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.


Question: 12.34. <ins> GNAP allows the RO to be contacted by the AS asynchronously, outside the regular flow of the protocol.  This allows for some advanced use cases, such as cross-user authentication or information release, but such advanced use cases have some distinct issues that implementors need to be fully aware of before using these features. First, in many applications, the return of a subject information to the client instance could indicate to the client instance that the end-user is the party represented by that information, functionally allowing the end-user to authenticate to the client application. While the details of a fully functional authentication protocol are outside the scope of GNAP, it is a common exercise for a client instance to be requesting information about the end user.  This is facilitated by the several interaction-start defined in GNAP that allow the end user to begin interaction directly with the AS. However, when the subject of the information is intentionally not the end-user, the client application will need some way to differentiate between requests for authentication of the end user and requests for information about a different user.  Confusing these states could lead to an attacker having their account associated with a privileged user.  Client instances can mitigate this by having distinct code paths for primary end user authentication and requesting subject information about secondary users, such as in a call center.  In such use cases, the client software used by the resource owner (the caller) and the end-user (the agent) are generally distinct, allowing the AS to differentiate between the agent's corporate device making the request and the caller's personal device approving the request. Second, RO's interacting asynchronously do not usually have the same context as an end user in an application attempting to perform the task needing authorization.  As such, the asynchronous requests for authorization coming to the RO from the AS might have very little to do with what the RO is doing at the time.  This situation can consequently lead to authorization fatigue on the part of the RO, where any incoming authorization request is quickly approved and dispatched without the RO making a proper verification of the request.  An attacker can exploit this fatigue and get the RO to authorize the attacker's system for access.  To mitigate this, AS systems deploying asynchronous authorization should only prompt the RO when the RO is expecting such a request, and significant user experience engineering efforts need to be employed to ensure the RO can clearly make the appropriate security decision.  Furthermore, audit capability, and the ability to undo access decisions that may be ongoing, is particularly important in the asynchronous case. </ins> An attacker may aim to gain access to confidential or sensitive resources.  The measures for hardening and monitoring resource server systems (beyond protection with access tokens) is out of the scope of

Fine ;-) (on my side, I always tend to consider CIBA as some degenerate phishing experiment, but maybe that's too extreme)


Question: Store the mDNS hostname and its related IP address in the ICE agent for future reuse. <del> Replace the IP address of the ICE host candidate with its mDNS </del> <ins> Replace the IP address of the ICE candidate with its mDNS </ins> hostname, and expose the candidate as usual. An ICE agent can implement this procedure in any way so long as it

PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?


Question: shown below. The derivation process is as follows, where L denotes the length of <del> the underlying hash function for HKDF RFC5869. </del> <ins> the underlying hash function for HKDF RFC5869.  SS and ES denote the sources from the table above.  Whilst SS and ES may be the same in some cases, the extracted xSS and xES will not. </ins> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.

Just a few things I noticed that I think make it a little bit easier to follow. Name resumption_secret consistently when used Show full legend for each handshake flow Simplify/clarify secret sources table a bit and make text cases consistent The resumption secret naming was also apparently noticed by NAME in issue . (Edited to note: this PR has been pruned down to a smaller list of changes; see commit message)
Ok, to respond to comments I've pushed a new commit. RE: capitalization: Upper or lower is fine, as long as it's consistent. I've switched it to all upper (title case) instead of all lower. RE: legend repetition: If you're just reading one section, e.g. got to it via TOC, you might not have seen the legend (recently). I've made it less wordy now and also added a line to indicate "+" is for extensions, as I realized that wasn't necessarily clear. (and added a "+" where the notation was inconsistent) We do have an extension that was previously a message, now. The basic point is consistency; make each handshake flow make sense on its own. I think repeating the legend is helpful, but if you really don't want to repeat it that I can cut this down to just the little stuff and table. Showing "N/A" instead of repeating things in the table is the most helpful part here, I think. It states that SS=ES in some circumstances elsewhere, but the table isn't clear that these are the exact same values, especially because the extracted ones are not.
Edited again and repushed for some more naming consistency.
Revised & rebased. Of note, I think these changes to the table make it far easier to see what's going on here.
NAME If you're going to be rewriting this, I'll just set those parts aside. The commit here is now just the little stuff: fix the spacing, add a line stating what SS/ES are in the list of derivations, and fix "shared_secret" (there's no such value named that; just drop the underscore).
NAME commit updated with fixes for your comments above
The key derivation process uses the "master secret" as the basis for application traffic keys and both the resumption and exporter secrets. There are lots of other secrets though.


Question: shown below. The derivation process is as follows, where L denotes the length of <del> the underlying hash function for HKDF RFC5869. </del> <ins> the underlying hash function for HKDF RFC5869.  SS and ES denote the sources from the table above.  Whilst SS and ES may be the same in some cases, the extracted xSS and xES will not. </ins> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.

I don't have a better name right now, so close this if none better can be found. Also s/resumption master secret/resumption secret/ throughout, it's a little inconsistent.
Now master of more


Question: default of 53).  DNS URIs normally omit the authority, or specify an IP address, but a hostname and non-default port number are allowed. <del> When a non-default port number is part of a service identifier, Port- </del> <ins> When the binding authority specifies a non-default port number, Port- </ins> Prefix Naming places the port number in an additional a prefix on the <del> name.  For example, SVCB records for a DNS service identified as ""dns1.example.com:9953"" would be located at </del> <ins> name.  For example, if the binding authority is ""dns1.example.com:9953"", the client would query for SVCB records at </ins> ""_9953._dns.dns1.example.com"".  If two DNS services operating on different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative

This should help with the case in DDR. See URL
Much better. Thanks for indulging me.


Question: The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. <del> 7.7. </del> <ins> 7.8. </ins> Including a "Date" field in requests reveals some information about the client clock.  This might be used to fingerprint clients UWT or

NAME noted that it was important to note that the Gateway needs to be trusted if gateway != target. As a practical matter, that means that you probably want gateway == target.
Hi, Since the gateways are seeing request/response pairs, there is a potential here for a side-channel attack at the gateway itself or at a relay. (if I understood the draft correctly - if not, please clarify my misunderstanding here). Are there mitigations planned for this type of issue that you could expand on in the Security Considerations section perhaps?
Does the new text in address this concern?
I don't think so, because the claim is the gateway does not have intimate knowledge of the contents of the request/response. If that assertion is true, the gateway shouldn't be able to ascertain information about the actual contents from those pairs (directly or indirectly, via a side-channel attack). If the burden is on the application developer to ensure that request/response pairs traversing the gateway are to be resilient to side-channel attacks of those pairings, then it would be good to explicitly call that out in this spec (perhaps in the security considerations section?) Thoughts?
NAME the gateway necessarily sees all request and response pairs, and will therefore always learn information about each transaction. This is fundamental to the design. Whether or not the gateway uses that information for malicious purposes, e.g., by providing different responses to different requests for the same target resource, depends on the trust model. And the change in addresses that. I don't think further text is needed here.
"Finally, a relay can also generate responses, though it assumed to not be able to examine the content of a request (other than to observe the choice of key identifier, KDF, and AEAD), so it is also assumed that it cannot generate an Encapsulated Response." I feel that a relay could certainly perform a side-channel attack here as well using R/R pairings.
Can you please be more specific here? What type of attack could the relay do to violate client privacy that is not already documented in the draft?
Typically in HTTPs scenarios, it is more difficult to perform side channel attacks as a flow observer, especially if multiplexing of requests and responses are performed.


Question: The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. <del> 7.7. </del> <ins> 7.8. </ins> Including a "Date" field in requests reveals some information about the client clock.  This might be used to fingerprint clients UWT or

In this design, if I understand it correctly, the requests and responses are being broken out into distinct exchanges that the relay can see and therefore it makes it easier for a relay to perform these types of attacks that would be more difficult had the relay not been used in the first place. If my understanding of the protocol is incorrect here, please feel free to point that out.
You seem to be describing fingerprinting attacks, wherein the observer uses features extracted from otherwise encrypted traffic to try and learn information about the underlying (unencrypted) data. Yes, the relay does have a more fine-grained view of each exchange compared to a network observer in this protocol since it can see explicit message boundaries, and that might impact the efficacy of these attacks. This is partly already addressed in the document: We could extend this to note the relay's view of message boundaries. I don't think any additional text is needed for the gateway.
Whatever you feel is best. I think some language around the message level risks this creates vs non-relay scenarios might be helpful. Does the client intentionally break things up in a way that crosses the underlying application message boundaries (e.g. more like packetization) with a relay? I have more questions about the gateway functionality that we can discuss separately.
This means that the client really needs to trust that the gateway doesn't muck with it. As a practical matter, this incentivizes clients to choose a gateway that is effectively the same entity as the target. They don't have to, but the amount of trust required of the gateway is higher if gateway and target aren't operated by the same entity. We touch on this, but we could be clearer about it.


Question: 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.

Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 0d7a49a6be4a9740f850d2477b1f2462de781b10 Inspect the deploy log: Browse the preview:
Section 2.2 is currently called: Then the text continues with: This means that this section is currently restricted to the RO. Since this call is restricted to the RO, the title of this section should be changed into: Requesting RO Information. In addition, the reason(s) for requesting such information is not mentioned and should be explained. As a side-consequence, a user has no on-line means to know which personal data the AS knows. This comment also impacts the content of section 1.4.6 (Requesting User Information). This topic has been first addressed under the issue which is still open. It would be wise to allow such an on-line access so that the user can know which attributes are known by an AS and then choose which attributes to insert into an access token.
Maybe we'll need a bit of rewording, although I'm not sure the proposed changes help so much. I just think we should put more emphasis (and state early on) what is shortly described at the end of section 4, i.e. that here RO = end-user
RO = end-user is not the general case. The usefulness of supporting Requesting RO Information is not crystal clear and should be indicated, but there is an interest to support Requesting User Information. While I agree with you that "we'll need a bit of rewording", simply stating that RO = end-user in section 4 will not solve the issue.
I notice that states It also shows that there is no RS involve and diagram uses label: User (not RO) To my understanding End-user is "logged in" to the client instance. Given role definition: If we don't have RS involved, so we also don't have any Protected Resource here, does it really make sense to speak of Resource Owner?
Yes, that's why we talk about the "user" here. Notice that currently, this term is used when we don't know the exact role it will play in the protocol (end user or RO).
If that's the case for why does speak about Resource Owner?


Question: 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.

Again in 2.2 we also don't seem to have Resource Server or Protected Resource involved.
The rationale is : in the intro of section 4, gnap allows a large variety of cases. GNAP can handle UMA2 types of scenarii (hence 1.4.6 and a few other places) but in gnap core we mostly detail the case where end-user = RO. Hence what we explain about the subject, and it makes sense to limite the diffusion of confidential information about the RO (the most limiting case, hence 2.2 and a few other places) That's actually a quite subtle difference, but i think it makes good sense.
Given above definitions maybe it would make sense to broaden definition of RO to: subject entity that may grant or deny operations on resources or obtaining assertions it has authority upon. Since in the User acting as RO doesn't grant or deny operations on resources (served by RS) but only grants / denies obtaining an assertion.
I agree that the specific language that NAME references should be tightened up. What's a little awkward right now is that GNAP's language treats access to an RS and access to information contained in assertions as protected resources, but it doesn't do so particularly cleanly due to several major text revisions that have changed things a little out of sync with each other. Both data from an RS (using an access token) and assertions/identifiers passed to the client are targeted at the client itself, so in that way they're the same nature, a protected resource after a fashion and both controlled by an RO of some kind. What's different is that the info passed back directly is usually assumed to be :about: the end-user, because that's what the client is calling about in just about all the use cases that are known. Technically all of the information, either from an RS or subject information passed directly, is controlled by the RO. The end-user can get involved through interaction and act as the RO. The case where the RO doesn't equal the end-user is useful in many situations but leads to unexpected weirdness when you're talking about the subject information coming back.
Fair point. We might start by listing what needs to be changed.
I tend to think of the AS as having a separate service endpoint for RO requests because they are the ones that can edit AS policy.


Question: 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.

A service endpoint that is accessible to End User requests would be "separate" and could be used by anyone including the RO when they want the protection of least-privilege. This distinction may be unhelpful in the general case of explaining GNAP so I don't mean to overstate it.
NAME when you say "service endpoint" are you thinking of something that's interactive and user-facing (so a webpage) or something that's a callable API?
NAME I really don't know enough to answer purely technical questions. I think mostly in terms of privacy engineering and look to this group for security and devops perspective. Therefore, I focus on the AS as the primary, if not the sole, entity that stores and executes RO policy. The AS takes requests and turns them into access tokens. The requests might be via (RAR) API or a web form. Either way, this request interface is likely unsecured. Some requests present credentials while others might add an authentication flow. That begs the issue of how did the AS get the RO's policies to begin with, long before a request comes in? I would define whoever sets the AS policies as the RO (regardless of any particular RS-RO relationship). A so-called "policy manager API" has been under discussion in UMA for about a year because at least one implementer wants to author policies on a mobile app and standardize the way they are uploaded to the AS. Back to Justin's technical question, I'm trying to implement the shortest distance between OAuth 2 and GNAP in a way that I can understand and explain to others. I'm doing this in FastAPI (because I don't know much beyond elementary Python, because it has built-in OpenAPI documentation, and has some OAuth 2 and JWT functionality). I'm deploying (automagically) to DigitalOcean App Platform in order to be clear about my various security and build shortcuts. I've designed the demo as two separate FastAPI server domains for the RS and AS. A "global" CouchDB instance is deployed for RO policy storage and any state that needs to be saved as part of the protocol demos.


Question: 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.

-- URL (the AS) and running at https://ognap-URL -- URL and running at https://ognap-rs-URL -- URL The protected resource is going to be_ just a self-verifying vaccine credential (I invented) -- URL -- Some of this is running at URL I've been stuck trying to answer Justin's exact question for quite a while. I think I need to set up the AS (OGNAP) to deliver a PWA to the RO so they can edit policies locally in PouchDB and sync the polices with the CouchDB the AS can access when a request comes in. That forces me to learn URL or something like it. Aside from my long-term goal to upgrade the HIE of One Trustee demo from UMA to GNAP, I'm also hoping to show the W3C and DIF protocol groups how easy it could be to mitigate significant OAuth 2 human rights concerns using GNAP. Any suggestions, help, moral support would be really welcome.
back to NAME and NAME : looking again on this. I guess we could define what we mean by operations. Getting an assertion is an operation, in my view. Or give it as an example. What do you think ?
I think it comes down to whether or not we consider the "subject information", which includes both identifiers and assertions, to be "resources" or not. I always thought they are, but they are definitely a different style of resource than what comes from the RS so maybe we need better wording around it. We talked about it a bit in the long terminology discussion a year ago, but I don't think we ever really landed on a term that fully captures "stuff sent directly to the client by the AS and not accessed through the RS". Identifiers and assertions are the two categories where there's clear demand, but other things could happen through extensions as well.
Does this issue also have to align with authentication flows that build on GNAP? a subject presents a DID or other identifier to a relying party (RP) the RP dereferences the identifier to an AS they trust a request for assertion is made to the AS the AS issues a liveness challenge to the subject the AS returns an assertion and attributes to the RP (the attributes might be accessed indirectly via an access token returned with the assertion) How is SIOP planning to handle this?


Question: 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.

In the current draft, section 2.2 : "The AS can determine the RO's identity and permission for releasing this information through interaction with the RO (Section 4), AS policies, or assertions presented by the client instance (Section 2.4). If this is determined positively, the AS MAY return the RO's information in its response (Section 3.4) as requested." Currently, a resource is just a short cut for "Protected resource", which really refers to an API served by a RS. So we have a mismatch (or at least a missing case) in the RO definition (as pointed out by NAME and NAME I've tried some sentences to specify subtypes for resources, but it becomes very confusing. The proposal by NAME to define the RO as "subject entity that may grant or deny operations on resources or obtaining assertions it has authority upon." seems slightly incorrect to me, because the assertion is not made by the RO, but by the AS. What the RO grants to the AS is access to its attributes (and then the AS may carry out further due diligence to derive assertions, for instance through AuthN flows as suggested by NAME The decision to disclose or not its own attributes is not restricted to the RO, it's actually something under the control of every subject. So here's what I'd suggest to solve the issue (new part in bold): update the definition of "Subject: person, organization or device. It decides whether and under which conditions its attributes can be disclosed to other parties." question 1 : should we limit this to physical persons? (from a legal perspective, that makes sense, but then wouldn't an org want to restrict what it shares, cf issues around data sovereignty?). I think the principle could be generic. question 2 : I've added under which conditions because we already discuss that in the text (manual consent, automatic policy, etc.), plus it's not only a yes/no, it also concerns what those other parties can do with it, including further sharing those attributes, cf the case mentioned by NAME where the AS sends them to the RP. Feedback welcome !
section refers to the Subject exclusively as RO. I'm still uncertain if the subject who in interaction only decides to disclose some attributes in an but not any "Protected resources" (an API served by RS) is considered to act as RO.


Question: 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.

If that's the case what would be the case where the subject decides to disclose some attributes but doesn't act as RO?
I'm not entirely sure about the use case you're targeting here. Could you be more specific ?
Maybe I shouldn't have mixed two questions together. Let's focus on one of them first. section always refers to the Subject as RO. In your previous comment you mentioned that: When we would have a situation where a Subject is deciding to disclose its own attributes but they don't act as RO?
In theory section 4 allows other situations (at the beginning of the section). But the only case that's detailed is the case where it is indeed the RO.
Thanks, now for the second part of my question. In we find: In this scenario, while no RS is participating, so no Protected Resources are being accessed. We still have Shouldn't definition of RO should still be broadened from current Keeping in mind It might still be something in direction of subject entity that may grant or deny operations on resources or obtaining assertions containing attributes it has authority upon. In short, if RO plays role in . There seems to be more to that role than just granting or denying operations on resources (an API served by RS).
My view is that the attribute part is covered by the fact that the RO is a subject (obtaining them is covered by the subject definition now). The main rationale for the protocol is still related to access to protected resources, and I believe we would dilute that otherwise.
In that case is there any reason for to still include: I think 4 could be removed altogether and 5 could become (after renumbering) This section states in the first sentence that it does not involve RS and access to protected resources (an API served by RS)
We still need to make sure that the user is indeed the RO, hence step 4.
I still consider that the information about the subject is counted among the "Resources" being released here. The only real difference is that instead of them being at an RS, they're passed directly to the client instance.
Yes, this didn't change. I'm only saying I don't think it needs to be embedded into the RO definition, since we can assume from the subject definition itself that some mechanism exists to grab the subject attributes data if it consents to.


Question: 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.

Changing the RO definition or worse the (protected) resource definition makes the entire thing convoluted, at least in every variation I tried.
NAME Right, and I think I agree with that. The definitions should try to stay tight, if we can. But if the surrounding text, especially the "subject information" request stuff isn't clear, then this is going to come around again. I don't have a specific answer but I would be surprised if we can't improve this, since it's come up a few times.
I am supportive of elf-pavlik when he writes: fimbault agrees with him when he says: When looking at Section 3.4 that is indicated in that section, the following text may be found. If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information in the "subject" response field. The case where information is about the end-user is not addressed, i.e. there is no sentence starting with: If information about the end-user is requested (...) Does this mean that an end-user is not allowed to know which personal data is known by the AS about him ? If this would be the case, such a limitation would not comply with generally agreed privacy principles. The text is still not fixed in draft-08. What are the benefits for a client to know information about the RO ? This may be crystal clear for the editor(s), but it is unclear for a lambda reader.
Based on recent conversations, especially URL it seems to me that the intention is to consider the subject as RO with regards to the information about them. I think this shows up clearly in since it does not involve any Protected Resources but it stills call the user RO. It might be helpful to document scenarios where there is more than one AS involved. Let's say we have Alice using a client to access resources owned by Bob. Here we could have two different AS: AS providing user information about Alice to the client - here Alice would act as both End-user and RO and Bob not be involved at all AS providing access_token to the client allowing access for protected resources - here Alice would act as End-user and Bob as RO Does that scenario with two different Authorization Servers sound reasonable?
NAME Those two both make sense, and it makes sense even for them to be together.


Question: 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.

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:


Question: _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.

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.


Question: _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.

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.


Question: _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.

Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity? Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Comment > Does the Authentication Secret represent the identity of the Attesting Environment? Comment > How to understand the Authentication Secret, and is it necessary all the time? For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well.


Question: _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.

From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren't protected separately, and they finally becomes the Evidence (TPM Quote) and it's only protected by the TPM's AIK. So, what is the Authentication Secret? Section 7 Generic Information Elements Attester Identity ('attesterIdentity'): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. Comment > Previous section says "Attester Identity" is about "a distinguishable Attesting Environment", and here says it's about "a distinguishable Attester". Comment > How to understand "without accompanying evidence about its validity"? Attester Identity ('attesterIdentity'): mandatory In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Comment > I think here means the DAA credential represents the Attester Identity. Comment > There is ambiguity of "that is randomized", does it mean randomized Endorser or randomized credential? Comment > For "confirm the validity of their evidence", what does "their" refer to? And what does "the validity of evidence" mean? Authentication Secret IDs ('authSecID'): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence. Comment > Previous section says "Authentication Secret" is used to protect Claims, but here says it's used to protect Evidence. Comment > As I understand, if Authentication Secret represents the identity of Attesting Environment, then it's not mandatory, at least in our implementation. Authentication Secret IDs ('authSecID'): mandatory In DAA, Authentication Secret IDs are represented by the Endorser (DAA issuer)'s public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence. In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments.


Question: _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.

This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Comment > In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the "Attester Identity" part, what does the DAA credential represent actually? Reference Claims ('refClaims') mandatory 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?] Comment > I suggest using Reference Values to keep consistent with the RATS arch. Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. Comment > "Direct comparison" isn't the correct expression, the comparison can have other rules. Claim Selection ('claimSelection'): optional A statement that represents a (sub-)set of Claims that can be created by an Attester. Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection. Comment > The "all Claims" may be ambiguous, I'd like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection? Section 8.1 Challenge/Response Remote Attestation Comment > In the sequence diagram, some elements in the bracket are not defined in the "Information Elements" section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined? Section 9 Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section. Comment > Here starts to talk about "additional requirements", but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements? Regards & Thanks! Wei Pan


Question: 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

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


Question: 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.

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 .


Question: 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>

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.


Question: 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>

: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