Original text:
hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values: <del> The RFC3986 at which the IdP's service is hosted.  Note that this may include a non-default port or a userinfo component, but neither will be available in a certificate verifying the site. </del>  The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to

Reviewer comments:
Need to address Ben's points.
Working group consensus to remove non-default port capability from the specification. In line with RFC 5785bis's guidance in Section 3. Thanks for addressing my Discuss points! I'll leave the original Comment section below, as I note that at least one issue remains (I spot-checked the SDP Offer/Answer reference, that still points to RFC 6454, which is "the Web Origin Concept".  I didn't make any attempt to trim points that did get addressed. (My comment about TCB and the other browser from the companion document is probably relevant here, too.) This is the optimistic "best security" case, and we already say we're talking to the signaling server over HTTPS, so it should be safe to just say "over TLS" and drop the "preferably".  (Also, s/5246/8446.) I think I'm confused.  We're displaying trusted browser chrome based on an assertion from some IdP that we have no relationship with and no reason to trust? nit: that's not really more specific.  Maybe "Once the requisite ICE checks have completed"? I see that the 4566 <base64> includes the pad characters, though sometimes we will mention explicitly whether they are or are not included. leading whitespace, too, right? 6454 is "the Web Origin Concept"; presumably this is supposed to be 4566 (or 3264?). I feel like we need some text here about the (non?)trustworthiness of the IdP. I'm a bit confused at what's going on here.  Is "MAY send the same" supposed to prevent changing it?  If I don't send it, does that identity continue to apply to the existing DTLS connections but not any new ones generated by the session modification?  Am I allowed to send a different one? nit: is this "each media section"/"every media section" redundant? There may be some (weak) privacy considerations if this is literally anyone, since it would allow some observers (with weird abilities/restrictions) to associate "real" identities with keys in a way that they couldn't otherwise do. Just to check: this last sentence applies for one-time requets, too? Does this need to be an exhaustive list or can we leave it open-ended? Also, it may be appropriate to mention some concept of "IdP trusted to authenticate the stated identity". Do we need to say anything about that state transition being visible to the peer, here? nit: s/windows/window/? Is there anything to say about why clients might not opt to do so (and what such approval might look like)? (My comments about "verified user" including the IdP in some way will apply here as well.) Is the "the current WG consensus" language going to age well? Is there a WIP draft for this separate document? nit: maybe make it more clear that this only applies for incoming calls? It's not clear to me that the "that is" reflects a strict equivalence; would "in particular" be more appropriate? (Also, "cipher suite" is a DTLS term, but do we want to disambiguate explicitly?) [obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note] "MUST NOT implement" isn't really something that 2119 language can enforce; "MUST NOT use" is the best we can get. (7918 doesn't claim to be applicable to DTLS anyway) nit: might be appropriate to note why we care about a super-cookie (and what it is) I'm not sure I see anywhere that we allow the usage of null ciphers. I agree with Alissa that the first person is not needed here. This probably needs some qualifier, given recent developments with CAA and similar mechanisms. The RP still needs to establish somehow that the IdP in use is in fact an authoritative IdP, though! A reference to that W3C API spec might be handy. nit: the grammar is a bit weird here, as the "information from the signaling message" isn't really a part of this work, but rather the specification for what information that is. The indentation of the line with "}, {" is a bit confusing. I'm a little confused what this "encoded in a JSON string" is supposed to mean. The IdP probably wants to know enough about its structure to not turn into a signing oracle for other protocols, though. (RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention that.) It's a little surprising to see sha-1 fingerprint in use (since "examples are recommendations"), though I didn't find anything that would actually formally deprecate such usage yet. leading whitespace, too, right? (Still need to say how it's know than authoritative assertions are in fact authoritative for what they claim.) (IdP still doesn't want to become a signing oracle.) nit: it's unclear that "serialized into JSON" adds any value, since the thing is defined to be a JSON object. I think that the framing of HTTP Basic (7617) here is not great. RFC 7235 might be a better link for HTTP Authentication in general, and of course there are mechanisms that don't include sending the password in plaintext, like SCRAM (RFC7804). IMPORTANT: Do we need a freshness property for the assertion?  Some of these schemes do not provide freshness. (Doesn't the W3C API spec need to say how the response is formatted?  Is the JSON formatting actually "illustrative" then, or is this just an example output?) Reading closely, I think this is supposed to be "unless either", but it's easy to assume it should be read as "unless both", so I think clarification is in order. We just said in the first paragraph that "user" has "any character except '@'", so this is a bit redundant. I suppose an "untrustworthy" IdP is basically a malicious one, though there are perhaps some subtleties that could be distinguished here. I don't think I fully understand the scenario described in this last sentence.  Is "compute digital signatures" supposed to be with some specific secret key, and/or is "a browser's generated key" one that is covered under the fingerprint in the IdP assertion? nit: "linkable information that would allow them to correlate the browser across multiple calls". I think I'm missing a step here.  How is the attacker using the data channel directly when the point is to get the multiple browsers to send the data on the data channel? nit: "must be used to suppress the misbehaving flow", I think. I don't see an "origin" field in the signature request; is this supposed to be the "domain"? nit: it might be friendlier to the reader to prefix this with "When popup blocking is in use, ". It's perhaps debatable that JSEP is only an informative reference.

Revised text:
hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values:  <ins> The RFC3986 at which the IdP's service is hosted. </ins> The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to