Subject: [rtcweb] WebRTC REF for OAUTH based TURN

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Mar 2018 08:14:23 -0600

From a dependency point of view, I would like to note that right now the WebRTC PC spec references

* draft-ietf-oauth-pop-key-distribution

Which rumor has it has been replaced by 

* datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz

Which normatively references the following:

* draft-ietf-ace-cbor-web-token
* ietf-ace-cwt-proof-of-possession
* draft-ietf-ace-cbor-web-token
* draft-ietf-ace-cwt-proof-of-possession

More discussion of this at https://github.com/w3c/webrtc-pc/issues/1642

What needs to happen with all this so we can finish up the stuff WebRTC needs to reference from IETF ?

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Mar 2018 17:53:47 +0000

I believe that
draft-ietf-oauth-pop-key-distribution
morphed into:
draft-ietf-ace-cwt-proof-of-possession/
I will double check with the ace chairs.

There is one downref to draft-ietf-ace-cbor-web-token, but it’s state is now "Approved-announcement to be sent::Revised I-D Needed for 5 days”

spt

> On Mar 13, 2018, at 14:14, Cullen Jennings <[email-masked]> wrote:
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Mar 2018 08:37:31 +0100

>From a WG product management point of view, I consider that this has not
deployed, and is not likely to deploy in the present timeframe, given
that no consensus specifiation has emerged.

My suggestion would be to replace this text:

An OAuth 2.0 based authentication method, as described in [RFC7635]. It
uses the OAuth 2.0 Implicit Grant type, with PoP (Proof-of-Possession)
Token type, as described in [RFC6749] and [OAUTH-POP-KEY-DISTRIBUTION].
 .... rest of section ....

with

 An OAuth 2.0 based authentication method, as described in [RFC7635].

The amount of detail currently in the webrtc-pc document is, to my mind,
inappropriate for a W3C spec. If the IETF has failed to come up with a
single "handle" by which all this detail  can be referenced, the IETF
needs to solve that problem.

---

From: Sean Turner <[email-masked]>
Date: Wed, 14 Mar 2018 09:33:20 +0000

> On Mar 14, 2018, at 07:37, Harald Alvestrand <[email-masked]> wrote:
> 

This seems to be like the right approach.

spt

---

From: Sean Turner <[email-masked]>
Date: Wed, 14 Mar 2018 09:59:46 +0000

> On Mar 14, 2018, at 09:33, Sean Turner <[email-masked]> wrote:
> 
> 
> 

For more info:
draft-ietf-ace-oauth-authz
Says:

  COSE is used to secure self-contained tokens such
   as proof-of-possession (PoP) tokens, which is an extension to the
   OAuth tokens.  The default token format is defined in CBOR web token
   (CWT) [I-D.ietf-ace-cbor-web-token].

ace-cbor-web-token is in Approved-announcement to be sent::Revised I-D Needed for 6 days
with no DOWNREF..

spt

---

From: Mészáros Mihály <[email-masked]>
Date: Wed, 14 Mar 2018 16:05:21 +0100

> needs to solve that problem.
After the confusion around RTCIceCredential OAuth parameters in
WebRTC-PC, I just want to close the gap between W3C WebRTC-PC and IETF
RFC7635.
RFC7635 is complex and confusing without a guide.
My intention was to remove confusion and define an example guideline
howto use RFC7635 in WebRTC context, and put all this info into the
WebRTC-PC spec.

Now I see I went too far, and PC spec should step back and mention OAuth
PoP only as a possible way of the key distribution, but in other hand
the information in webrtc PC is inline with the RFC7635 example Appendix B.

Is it better to leave totally undefined howto use RFC7635 in WebRTC
context as Harald proposed?
I am not sure.

Misi

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Mar 2018 17:46:49 +0100

> context as Harald proposed?

I think it would be better to publish an IETF document that describes
"one clear way to do it", and see if we can get interoperable
implementations of that. Then we can insert a reference to that in the
WebRTC spec when it's ready.

The current text is unimplementable because it refers to documents that
don't exist (formally) any more, which is an untenable situation.

Harald

---

From: Mészáros Mihály <[email-masked]>
Date: Mon, 19 Mar 2018 13:51:47 +0100

> don't exist (formally) any more, which is an untenable situation.
I started my discussion with Simon in TRAM wg. chair about it. The
conclusion was it is not clear if IETF informational RFC is the right
place to put it.
That time it seem the oauth-pop-key-distribution is the only way howto
implement it, (RFC7635 also gave in appendix an example based on it).

I thought that RFCs/specs are already so heavily fragmented in this
topic, and it's easy to get lost in RFCs,
even to understand OAuth & PoP, so it would be the right place to put
the specialities in WebRTC context in WebRTC PC spec..

After my various failed PRs Taylor helped and put this text together.
I still believe that the actual text in PC is still a good guidance and
example howto implement it using RFC7635 + oauth-pop-key-distribution.

It is detailed enough to understand howto implement it.

Now during rereading it I recognized one mistake: It is wrong and
misleading from that aspects that it does not state that
oauth-pop-key-distribution is only an example of key distribution.

However I understand your reasons to move it out to an RFC, I still
don't know if it would help for implementers or not.
> don't exist (formally) any more, which is an untenable situation.
For me it seems easier to follow oauth (http) based key distribution,
and so for me it is still not so clear why the OAuth pop key
distribution is an obsoleted idea.

Personally I am not sure which way is more implementable today.
Please notice that CWT/CBOR PoP is also in draft state.

Both has pro and contra,

  * stable dead end VS. moving working draft
  * more stable VS. less mature in progress.

All in all both cwt-proof-of-possession and oauth-pop-key-distribution
are in working draft state and not yet an RFC.
For an RFC7635 implementer for WebRTC I think today it is still much
more easy and safe to implement oauth-pop-key-distribution (with coturn
open implementation backend).

All in all I would be happy to keep it inside WebRTC-PC with some slight
change, fix the mentioned issue:(oauth-pop-key-distribution is only an
example way of key distribution implementation),
because IMHO it would help for implementers a lot.

Sorry for my late reply.
Misi