Re: WebRTC REF for OAUTH based TURN

2018-03-14 17:46 keltezéssel, Harald Alvestrand írta:
> Den 14. mars 2018 16:05, skrev Mészáros Mihály:
>>
>> 2018-03-14 08:37 keltezéssel, Harald Alvestrand írta:
>>> Den 13. mars 2018 15:14, skrev Cullen Jennings:
>>>> 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 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.
>>>
>> 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.
> 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.
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.
> The current text is unimplementable because it refers to documents that
> 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