Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch)

From: Cullen Jennings <[email-masked]>
Date: Tue, 1 May 2018 17:47:16 -0600

> On Apr 30, 2018, at 9:20 AM, Tim Hollebeek <[email-masked]> wrote:
> 
> It's entirely possible that there isn't actually a problem if you do all the right things.
> But it's important that all those right things are actually required, and the rationale
> is clearly explained in the security considerations.  For example, doing certificate 
> expiration checks, so that there isn't crypto data lying around that can be used in 
> "interesting" ways in the future when the standard may have evolved into something 
> else, seems like a good idea to me.

I certainly think it would be worth advising the IdP protocols designers that they they probably want to consider making the tokens only valid for a short time such as 30 seconds and they are welcome to have a way to invalidate and check validity of tokens if they want to do that. 

> 
> I also think the musings in Martin's last paragraph make sense and are headed in the 
> right direction.  There's no harm in making protocols robust against attack scenarios
> we haven't thought of yet.

For sure - but we don’t want to do is make it so hard to use that no one uses. Something the IETF excels at :-) But as long as we can improve the robustness of the security without huge complication to use, I’m for that. 

> 
> -Tim
> 
>> -----Original Message-----
>> From: Martin Thomson [mailto:[email-masked]]
>> Sent: Monday, April 30, 2018 12:30 AM
>> To: Cullen Jennings <[email-masked]>
>> Cc: Tim Hollebeek <[email-masked]>; RTCWeb IETF
>> <[email-masked]>
>> Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-
>> security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch)
>> 
>> I agree with Cullen.
>> 
>> I would also point out that with an intended recipient, the IdP can limit the
>> information that can be obtained from an assertion.  If the assertion were
>> provided to other than the intended recipient, the IdP could refuse to provide
>> an identity.  That requires authenticating the recipient as well, which isn't
>> something we naturally assume, but the mechanisms for enabling that are all in
>> place.
>> 
>> FWIW, I think that an abundance of caution suggests that limiting the assertion
>> to a particular session is sensible.  The problem there is that we would need a
>> session identifier in order to do that.  Until we discovered that RTCCertificate
>> was portable, that was considered sufficient, I would prefer to remove that
>> portability.  Maybe we should consider adding an origin to RTCCertificate that
>> would allow it to be moved to other origins, but not be used by them.
>> 
>> On Sun, Apr 29, 2018 at 2:01 AM, Cullen Jennings <[email-masked]> wrote:
>>> 
>>> Tim - that sounds about right but this is the part I don’t get….
>>> 
>>> All the identity assertion does is bind the public key from the TLS
>>> connection to the a name/identity. Think of it like a certificate that
>>> binds my private key to name. Anyone can get my cert and pass it
>>> around however they want. That is fine. Similarly the assertion can be
>>> passed around handed to bad people etc. But anyone using it need to
>>> match it with a TLS connection that does proof of possession of the
>>> private key that matches the public key. That private key is going to
>>> be very narrowly scoped on what has access to it. People that want to
>>> rely on this identity assertion have to be sure that they require proof of
>> possession of private key.
>>> 
>>> So I do not see the issue at all that the identity assertion, just
>>> like a normal X508 certificate, can be passed around. I’m not getting
>>> whey this is Slightly Less than Awesome :-)
>>> 
>>> I’m not arguing there is no problem, but I am not getting what the
>>> problem is.
>>> 
>>> Cullen
>>> 
>>> 
>>> 
>>> On Apr 27, 2018, at 6:13 PM, Tim Hollebeek
>>> <[email-masked]>
>>> wrote:
>>> 
>>> I’m going from my memory from the IETF 101 hackathon here, so someone
>>> feel free to correct me if I’m remembering the details wrong (I
>>> probably am for at least some of it), but as I recall it, the issue
>>> was essentially that when one requests an identity assertion, if one
>>> presents it to someone, the security properties are Awesome [TM]
>>> because only authorized persons can get an identity assertion from the IDP.
>>> 
>>> However, after one has presented an identity assertion to a
>>> potentially untrusted party, presentation of that assertion to
>>> additional parties is Slightly Less Than Awesome [TM], because the
>>> additional parties cannot distinguish between the person who
>>> legitimately obtained the identity assertion, and the party to which
>>> the identity assertion was previously presented.
>>> 
>>> Various arguments were made that this is not a problem because the
>>> lifetime of identity assertions is short, with lifetimes on the order
>>> of days to hours.  There was also some discussion (before the issue
>>> was found) about if expiration of the relevant temporary certificates
>>> needed to be checked at all.  Call me crazy, but only having a few
>>> hours to carry out my attack doesn’t hinder me much as an attacker!
>>> 
>>> One solution that was discussed, which may or may not work for all use
>>> cases and this certainly should be explored, was that identity
>>> assertions are cheap and therefore supporting the complexity of
>>> identity assertion re-use might not make sense.  We discussed simply
>>> adding a nonce to the creation of identity assertions, so IDPs could
>>> enforce that they are validated only once, essentially turning them
>>> into bearer tokens.  If the process fails (network hiccup, etc) it is
>>> possible to transparently regenerate a new assertion and retry.  IIRC
>>> certain non-attack failure scenarios needed this retry logic anyway.
>>> 
>>> If needed, I can go back and re-read the messages from that weekend to
>>> help refresh my memory, but that’s what I remember.
>>> 
>>> -Tim
>>> 
>>> From: rtcweb [mailto:[email-masked]] On Behalf Of Cullen
>>> Jennings
>>> Sent: Thursday, April 26, 2018 9:03 PM
>>> To: Sean Turner <[email-masked]>
>>> Cc: RTCWeb IETF <[email-masked]>
>>> Subject: Re: [rtcweb] Addressing WGLC comments for
>>> draft-ietf-rtcweb-security-arch? (was Re: WGLC for
>>> draft-ietf-rtcweb-security-arch)
>>> 
>>> 
>>> 
>>> 
>>> On Apr 12, 2018, at 7:45 AM, Sean Turner <[email-masked]> wrote:
>>> 
>>> 1) Tweak protocol to include an identifier to prevent reuse of
>>> assertion on every RTCPeerConnection:
>>> 
>>> More complex sites frequently generate multiple RTCPeerConnection
>>> instances for their communications, especially for group
>>> conversations.  If the browser requests an assertion once and they use
>>> that value for every RTCPeerConnection, then that's OK.  From my
>>> perspective, I would be happy modifying the protocol to include an
>>> identifier and prevent that; for this the IdP can use caching or its
>>> local storage.
>>> 
>>> So, what would that look like?
>>> 
>>> 
>>> It’s not clear to me what the problem we are solving here is. Who are
>>> we trying to stop from reusing an assertion and why. The assertion is
>>> already bound to the specific private key and specific web origin. The
>>> IdP can bind it to a narrow time range if the IdP wants ( most do).
>>> I’m not seeing the big difference from reusing an assertion vs. asking the for a
>> bunch of them.
>>> The protocol that users the assertion may end up forking the same
>>> assertion to many places regardless of what the browser does.
>>> 
>>> Changing this so that the IdP see how many PeerConnections are formed
>>> seems like it just reveal more usage information to the IdP and does
>>> not help security.
>>> 
>>> Assuming I am just not getting the problem and we do want to solve
>>> this … I is not clear to me how to make this all work with tls-id due
>>> to all the bundle issues. Another approach would the browser greater a
>>> GUID for the PeerConnection and that is passed in the IdP proxy code
>>> and the IdP can bind it into the assertion or not but if it does bind
>>> into the assertion, then the browser will only validate the assertion
>>> on the PeerConnection with matching GUID. This is probably wrong and
>>> half baked as I don’t really get the problem.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 1 May 2018 17:47:54 -0600

> On Apr 29, 2018, at 10:29 PM, Martin Thomson <[email-masked]> wrote:
> 
> I agree with Cullen.
> 
> I would also point out that with an intended recipient, the IdP can
> limit the information that can be obtained from an assertion.  If the
> assertion were provided to other than the intended recipient, the IdP
> could refuse to provide an identity.  That requires authenticating the
> recipient as well, which isn't something we naturally assume, but the
> mechanisms for enabling that are all in place.

> 
> FWIW, I think that an abundance of caution suggests that limiting the
> assertion to a particular session is sensible.  The problem there is
> that we would need a session identifier in order to do that.  Until we
> discovered that RTCCertificate was portable, that was considered
> sufficient, I would prefer to remove that portability.  Maybe we
> should consider adding an origin to RTCCertificate that would allow it
> to be moved to other origins, but not be used by them.

I’m not following how the private keys move between origins  - how does that happen ? Sorry that I missed that part of the thread.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 01 May 2018 23:54:14 +0000

On Wed, May 2, 2018 at 1:47 AM Cullen Jennings <[email-masked]> wrote:
> I’m not following how the private keys move between origins  - how does
that happen ? Sorry that I missed that part of the thread.

In order to enable saving of RTCCertificate to indexedDB and the like, we
made it Transferable.  That means that origin X can use postMessage to send
it to origin Y.  That's the problem that was discovered during the
hackathon.

If our intent is to retain the ability to save, but not the ability to
move, then binding RTCCertificate to a single origin would work.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 2 May 2018 08:03:27 +0200

> move, then binding RTCCertificate to a single origin would work.

Actually the RTCCertificate is not marked Transferable (there is no such
annotation), but it does support structured cloning (in prose).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 02 May 2018 07:54:37 +0000

Thanks for the correction Harald.  I should have checked.

The point is that postMessage can be used to move it around.  Both
structure cloning and Transferable enable that.  (Transferable could indeed
be preferable because then at least only one origin could use the object at
the one time, but it's still not perfect.)
On Wed, May 2, 2018 at 4:04 PM Harald Alvestrand <[email-masked]>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 May 2018 07:34:15 -0600

Ok - that makes sense. But it can only be transferred between two JS apps that trust each other and are trying to share it. This sounds like a feature not a bug. I’m still missing the problem with this. 

> On May 2, 2018, at 1:54 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 03 May 2018 01:21:38 +0000

An IdP is given the origin of the requesting site.  That allows it to make
authorization decisions on that basis.  For instance, it might request
"login", but instead use that to do something similar to the OAuth
authorization interstitial pages that are common with federated logins: "
callsite.example.com wants to access your [email-masked] identity:
[allow] [deny]".

If callsite.example.com was then able to pass that along to others, that
invalidates the basic assumption that the IdP has.

There is also the principled position that says that private keys don't
move, rather the point should be have every context have its own keys and
to transfer properties to those keys.  I'm not aware of any use case that
can't be addressed by using indirection such that user X is known to have N
keys rather than 1.

(Those following this discussion might see similar thoughts echoed in <
https://github.com/w3c/webrtc-pc/issues/1853>.)
On Wed, May 2, 2018 at 11:34 PM Cullen Jennings <[email-masked]> wrote:

> Ok - that makes sense. But it can only be transferred between two JS apps
that trust each other and are trying to share it. This sounds like a
feature not a bug. I’m still missing the problem with this.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 May 2018 08:55:08 -0600

> On May 2, 2018, at 7:21 PM, Martin Thomson <[email-masked]> wrote:
> 
> authorization decisions on that basis.

Really ?  I don’t think it can trust that.  I can easily get my browser to send whatever origin I want to the IdP. I think it needs to do the usual OAuth like things to authenticate the user.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 May 2018 01:44:25 +0000

> Really ?  I don’t think it can trust that.  I can easily get my browser
to send whatever origin I want to the IdP. I think it needs to do the usual
OAuth like things to authenticate the user.

Yes, it can trust that.  Of course it still needs to authenticate the user,
but the origin it receives from the browser needs to be correct.

There's the attack where the IdP is instantiated by an attacker who
controls absolutely everything, including the origin, but the defense there
is that the attacker would also have to provide the IdP with authentication
credentials for the user and that's where it breaks down for the attacker.

---

From: Sean Turner <[email-masked]>
Date: Thu, 10 May 2018 10:39:53 -0400

Just wanted to make sure we don’t loose these.

> On Apr 27, 2018, at 02:10, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
>>> A couple of questions on the SDP identity attribute.
>>> 
>>> Q1:
>>> ---
>>> 
>>> The draft lacks the offer/answer procedure sections (generate offer,
>>> generate answer, modify session etc) for the attribute, which I think
>>> should be added. My question is regarding the following statement, which
>>> seems to indicate that the attribute is only used in offers:
>>> 
>>> "Implementations SHOULD only include a single identity attribute in an
>>> offer² (there is no text about including the attribute in an answer)
>> 
>> This is about what to do if you include a=identity not about whether to
>> include it.
> 
> When new SDP attributes are defined, there needs to be offer/answer
> procedures. Because, I assume the attribute can be used on the wire, in
> SDP offers and answers?
> 
> Also, if the attribute is scoped to WebRTC, or to some specific security
> solutions, I think that also needs to be covered.
> 
> 
>>> However, in draft-ietf-rtcweb-sdp it is included in both the offer and
>>> answer.
>> 
>> I think that draft-ietf-rtcweb-sdp includes them in both the offer and
>> the answer because the examples are using the WEBRTC Identity mechanism.
>> I think this is consistent with what is in both draft-ietf-rtcweb-sdp and
>> draft-ietf-rtcweb-jsep:
>> 
>>  If WebRTC identity is being used, an "a=identity" line as
>>  described in [I-D.ietf-rtcweb-security-arch], Section 5.
> 
> 
> That sentence is only for the initial offer. Unless I’ve missed it, there
> is no text about a=identity regarding answers.

Would making the following two change make it clearer that a=identity can be included in either/both:

1) s.5.6.3 (r/SDP offer/exchange transaction/SDP offer/answer exchange)

OLD:

   An identity assertion binds the user's identity (as asserted by the
   IdP) to the SDP offer/exchange transaction and specifically to the
   media.

NEW:

   An identity assertion binds the user's identity (as asserted by the
   IdP) to the SDP offer/answer exchange and specifically to the
   media.

2) s.5.6.4.1

OLD:

   Once an IdP has generated an assertion, it is attached to the SDP
   message.  This is done by adding a new identity attribute to the SDP.

NEW:

   Once an IdP has generated an assertion, it is attached to the SDP
   offer/answer message.  This is done by adding a new identity attribute
   to the SDP.

or we could go even further:

NEW:

   Once an IdP has generated an assertion, it is attached to the SDP
   offer/answer message.  This is done by adding a new identity attribute
   to the SDP; the offer includes the caller’s assertion; the answer includes
   the callee’s assertion.

Now as far as what more might be said to scope the attribute to WebRTC, I’m pretty sure that’s covered in two ways:

1) If folks are coming at this attribute from the IANA registry, then the “Appropriate Values” registry entry points to s5.6.4.2 of this document and that section pretty much gets you to using IdP as described in this draft.

2) If folks are coming at it from reading the draft/RFC, then well it’s pretty clear that this attribute is used with IdPs.

>>> Q2:
>>> ---
>>> 
>>> Also, the mux category is missing (draft-ietf-mmusic-sdp-mux-attributes
>>> also covers session-level attributes). I assume it is ³NORMAL².
>> 
>> I think this mans adding:
>> 
>> Mux Category: NORMAL
>> 
>> to the IANA registration?
> 
> Correct. But, NORMAL is just my assumption -  I want people to confirm
> whether that is correct :)

I submitted PR to address this:
https://github.com/rtcweb-wg/security-arch/pull/66

I included “NORMAL”, but if somebody thinks this is wrong I can change it. 

spt

> Regards,
> 
> Christer
> 
> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 23/04/18 01:47, "rtcweb on behalf of Martin Thomson"
>>> <[email-masked] on behalf of [email-masked]> wrote:
>>> 
>>>> tls-id is connection-based (i.e., it applies to a single bundle),
>>>> whereas identity is session-based.  That was my initial thought, but
>>>> then we have to deal with the 1:N problem there.  The simplest
>>>> approach might be to move a=identity to the bundle, but that leads to
>>>> some interesting downstream effects.  You probably want to avoid
>>>> having multiple identities in the same RTCPeerConnection, for
>>>> instance.
>>>> 
>>>> On Sat, Apr 21, 2018 at 11:10 AM, Eric Rescorla <[email-masked]> wrote:
>>>>> 
>>>>> 
>>>>> On Thu, Apr 12, 2018 at 6:45 AM, Sean Turner <[email-masked]> wrote:
>>>>>> 
>>>>>> The WGLC for this document has ended.  I think it was really good
>>>>>> that
>>>>>> @
>>>>>> IETF101 the IdP hackathon happened because it looked like they might
>>>>>> have
>>>>>> uncovered something to be changed in our document and possibly in the
>>>>>> webrtc-pc draft; see the [0] thread.  As the Shepherd trying to drive
>>>>>> this
>>>>>> to closure, we need to we need to decide what changes might be made
>>>>>> in
>>>>>> draft-ietf-rtcweb-security-arch.  In that thread, I saw two things
>>>>>> that we
>>>>>> might change (both from mt):
>>>>>> 
>>>>>> 0) More text to address a linkability concern:
>>>>>> 
>>>>>> As a practical matter, if the browser were to use the same
>>>>>> certificate
>>>>>> for multiple origins, then it would create a massive privacy problem
>>>>>> that enables linkability (aka user tracking).  I couldn't find that
>>>>>> written down, but I thought it was.  If it isn't written down, then
>>>>>> we
>>>>>> should correct that.
>>>>> 
>>>>> 
>>>>> Isn't this the relevant text:
>>>>> "
>>>>> 
>>>>>  API Requirement:  Unless the user specifically configures an
>>>>> external
>>>>>     key pair, different key pairs MUST be used for each origin.
>>>>> (This
>>>>>     avoids creating a super-cookie.)
>>>>> 
>>>>> "
>>>>> 
>>>>> 
>>>>>> 
>>>>>> I actually think this is basically covered here:
>>>>>> 
>>>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4.
>>>>>> 1
>>>>>> But want to make sure others agree:
>>>>>> 
>>>>> Wouldn't it be sufficient to include the tls-id in the identity
>>>>> binding?
>>>>> 
>>>>> -Ekr
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Did I miss anything else that needs to be addressed?
>>>>>> 
>>>>>> spt
>>>>>> 
>>>>>> [0]
>>>>>> 
>>>>>> 
>>>>>> https://mailarchive.ietf..org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7j
>>>>>> XE
>>>>>> w
>>>>>> 
>>>>>>> On Mar 12, 2018, at 19:08, Sean Turner <[email-masked]> wrote:
>>>>>>> 
>>>>>>> All,
>>>>>>> 
>>>>>>> This is the WGLC for the ³WebRTC Security Architecture² draft
>>>>>> available
>>>>>>> @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/.
>>>>>> Please
>>>>>>> review the draft and send your comments to this list by 2359UTC on
>>>>>> April
>>>>>>> 6th, 2018.
>>>>>>> 
>>>>>>> Note the gh repo is here:
>>>>>>> https://github.com/rtcweb-wg/security-arch
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> C/T/S
>>>>>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 May 2018 17:21:13 +0000

Hi,

>>>> generate answer, modify session etc) for the attribute, which I 
>>>> think should be added. My question is regarding the following 
>>>> statement, which seems to indicate that the attribute is only used in offers:
>>>> 
>>>> "Implementations SHOULD only include a single identity attribute in 
>>>> an offer² (there is no text about including the attribute in an 
>>>> answer)
>>> 
>>> This is about what to do if you include a=identity not about whether 
>>> to include it.
>> 
>> procedures. Because, I assume the attribute can be used on the wire, 
>> in SDP offers and answers?
>> 
>> Also, if the attribute is scoped to WebRTC, or to some specific 
>> security solutions, I think that also needs to be covered.
>> 
>> 
>>>> However, in draft-ietf-rtcweb-sdp it is included in both the offer 
>>>> and answer.
>>> 
>>> I think that draft-ietf-rtcweb-sdp includes them in both the offer 
>>> and the answer because the examples are using the WEBRTC Identity mechanism.
>>> I think this is consistent with what is in both draft-ietf-rtcweb-sdp 
>>> and draft-ietf-rtcweb-jsep:
>>> 
>>>  If WebRTC identity is being used, an "a=identity" line as  described 
>>> in [I-D.ietf-rtcweb-security-arch], Section 5.
>> 
>> 
>> That sentence is only for the initial offer. Unless I’ve missed it, 
>> there is no text about a=identity regarding answers.
>

Without commenting on the specifics above at this point, the structure we normally use is:

x.  SDP XXX Attribute    <--- This section defines the attribute
y.  SDP Offer/Answer Procedures
y.1.  General
y.2.  Generating the Initial SDP Offer
y.3.  Generating the Answer
y.4.  Offerer Processing of the SDP Answer
y.5.  Modifying the Session

> 1) If folks are coming at this attribute from the IANA registry, then the “Appropriate Values” registry entry 
> points to s5.6.4.2 of this document and that section pretty much gets you to using IdP as described in this draft.
>

Sure, and it would probably be enough to say that the attribute is applicable to entities that support/use IdPs. Then we don't need to say "WebRTC", because it is quite unclear what that really means.

----

> I included “NORMAL”, but if somebody thinks this is wrong I can change it. 

Assuming "NORMAL" is correct, the PR looks good :)

Regards,

Christer

>>>> whereas identity is session-based.  That was my initial thought, 
>>>> but then we have to deal with the 1:N problem there.  The simplest 
>>>> approach might be to move a=identity to the bundle, but that leads 
>>>> to some interesting downstream effects.  You probably want to avoid 
>>>>>> that @
>>>>>> IETF101 the IdP hackathon happened because it looked like they 
>>>>>> might have uncovered something to be changed in our document and 
>>>>>> possibly in the webrtc-pc draft; see the [0] thread.  As the 
>>>>>> Shepherd trying to drive this to closure, we need to we need to 
>>>>>> decide what changes might be made in 
>>>>>> draft-ietf-rtcweb-security-arch.  In that thread, I saw two 
>>>>>> things that we might change (both from mt):
>>>>>> 
>>>>>> certificate for multiple origins, then it would create a massive 
>>>>>> privacy problem that enables linkability (aka user tracking).  I 
>>>>>> couldn't find that written down, but I thought it was.  If it 
>>>>>> isn't written down, then we should correct that.
>>>>> 
>>>>> 
>>>>>> conversations.  If the browser requests an assertion once and 
>>>>>> they use that value for every RTCPeerConnection, then that's OK.  
>>>>>> From my perspective, I would be happy modifying the protocol to 
>>>>>> include an identifier and prevent that; for this the IdP can use 
>>>>>> caching or its local storage.
>>>>>>

---

From: Sean Turner <[email-masked]>
Date: Wed, 23 May 2018 08:55:09 -0400

> On May 10, 2018, at 13:21, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> Without commenting on the specifics above at this point

I went ahead and submitted PR:
https://github.com/rtcweb-wg/security-arch/pull/68
Martin pointed out that the 2nd suggestion for s.5.6.4.1 that the caller/callee distinction isn’t quite right because they aren’t always in the same offer/answer roles.  So I went with the first suggestion or s5.6.4.1.

> , the structure we normally use is:
> 

Luckily, there are a bunch of SDP attributes defined and some follow this structure and some don’t ;)  I’ll admit that I’m a little hesitant to suggest that we do a major editorial revision because the draft has basically had the same layout for 2+ years. 

> Sure, and it would probably be enough to say that the attribute is applicable to entities that support/use IdPs. Then we don't need to say "WebRTC", because it is quite unclear what that really mea…

What it says is this:

Purpose:  This attribute carries an identity assertion, binding an
      identity to the transport-level security session.

with the Appropriate values it’s pretty clear what goes in the attribute.

> Assuming "NORMAL" is correct, the PR looks good :)

Yeah I was kind of hoping that this PR would force people to comment ;)

spt