Subject: [rtcweb] RTCWeb and STIR

From: Cullen Jennings <[email-masked]>
Date: Mon, 9 May 2016 14:31:34 -0600

I've been looking at how WebRTC Identity and STIR work together and put together a worked out example at 

http://www.ietf.org/id/draft-jennings-stir-rtcweb-identity-00.txt

It does not propose any significant changes to WebRTC but it does point at a few syntax changes that might make things easier. 

Probably the key change for RTCWeb would be to unify the syntax we use for DTLS-SRTP fingerprints.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 10 May 2016 09:21:21 +0200

> Probably the key change for RTCWeb would be to unify the syntax we use for DTLS-SRTP fingerprints. 

The fingerprint syntax comes from SDP/DTLS, not from RTCWeb, I believe.

It might be best for STIR to either get with the party or propose an SDP
change for DTLS.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 11 May 2016 20:54:15 +0000

STIR is planning on moving the fingerprint syntax to a JSON array anyway.
I think we could easily get the PASSporT object aligned with the syntax in
rtcweb-security-arch 5.6.4. So I think the fixes in 3.2 can probably be
made - though I agree (per 3.7) we should try to make the encoding of the
digest as compact as we can across the two mechanisms, which might warrant
some more discussion.

The really interesting interworking question, as Cullen's draft suggests,
is how to prevent the "grossness" that results from the fact that STIR
today carries its identity assertion in a SIP header, whereas WebRTC
carries its assertion as an SDP attribute. The last thing we'd want is to
do both redunantly. It does look like, provided we can get fingerprints
into alignment, it would at least be possible to translate the SDP
attribute into a SIP header and vice versa.

A number of the smaller fixes that Cullen proposes for WebRTC seem like
they could be helpful: as some are just adding extensions to the existing
a=identity attribute, which the rtcweb-security-arch spec allows, so much
of that is painless. Support for multiple identity assertions in one SDP
session seems like it would be valuable for non-STIR IdP use cases even.
Questions like Cullen's 3.3.3, whether or not it would be better to break
the domain and protocol out of the base64 encoded assertion, are things
that would be nice to have, though I imagine people are reluctant to
reopen rtcweb-security-arch at this point.

Most of the questions about the identifiers carried in the assertion are
cases where, at least on the PASSporT side, extensibility should be able
to take care of them. The 3.6 question of whether identity should focus on
RFC822-style names versus URIs is an interesting one: I'd venture it would
be perfectly valid to define a PASSporT claim type for those, in addition
to having URIs and telephone numbers as options (also, there's already a
baseline JWS "email" claim that might serve). Per 3.9, I've been imagining
a PASSporT extension specifically for conferencing architectures -
possibly more than one will be required, to support centralized vs. mesh.

This is a very handy document to have though, I think I understand the
interworking story a lot better than I did before.

Jon Peterson
Neustar, Inc.

On 5/10/16, 12:21 AM, "rtcweb on behalf of Harald Alvestrand"
<[email-masked] on behalf of [email-masked]> wrote:

>> It does not propose any significant changes to WebRTC but it does point
>>at a few syntax changes that might make things easier.
>>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 May 2016 11:43:43 +1000

> interworking story a lot better than I did before.

wot jon sed

These are likely to be breaking changes, but I think that there are
changes in this direction that would improve the functioning of the
WebRTC identity stuff.  Some potentially a lot. Getting good STIR
PASSporT integration might be a big deal.