- From: misi via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Nov 2017 08:45:01 +0000
- To: public-webrtc-logs@w3.org
**HTTP vs CoAP?** RFC7635 refers to OAUTH-POP-KEY-DISTRIBUTION in the non normative part. In my understanding it refers mainly as the http transport between AS and OAuth client. Please notice that RFC7635 defines an _own defined special binary token_ (It does not use JWT!) so I think it may misleading to say that that ace-cwt-proof-of-possession is the relevant replacement of the OAUTH-POP-KEY-DISTRIBUTION (at least from the RFC7635 point of view). The ace-cwt-proof-of-possession is relevant only if we want to totally update RFC7635 to use CWT instead of the binary token that is defined in https://tools.ietf.org/html/rfc7635#section-6.2. IMHO the OAUTH-POP-KEY-DISTRIBUTION replacement it the draft-ietf-ace-oauth-authz And the main difference in my understanding is the request-response protocol replacement, so draft-ietf-ace-oauth-authz use CoAP, as the http replacement because of the constrained environment. > CoAP is an application layer protocol similar to HTTP, but > specifically designed for constrained environments. I think WebRTC 1.0 main use case is audio/video chat and most use case depends on http, so I don't think it would be big benefit to move this TURN auth credential information request form HTTP to CoAP in most cases! +1 CoAP as a new UDP protocol may could cause new firewall traversal problems.. **Options:** 1. do nothing stick as it is actually with http and OAUTH-POP-KEY-DISTRIBUTION 2. step back little bit in webrtc-pc spec and express that the OAUTH-POP-KEY-DISTRIBUTION (so http credential distribution) is only one way and so we give one example, and specify in normative part only that we need three information Access-Token, mac-key, kid and not define what protocol the client will use to get this information. 3. Update RFC7635 wit a new RFC to use CWT instead of own binary token. I could go along with all, but prefer 1 or 2 because of focus on stability, (avoid new features) and we because there is already a working implementation of RFC7635 in coTURN. The right solution maybe to rewrite RFC7635, so considering the option 3, but IMHO we should keep it back and do it in WebRTC-NV. Please let me know your thoughts! -- GitHub Notification of comment by misi Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1642#issuecomment-347113913 using your GitHub account
Received on Monday, 27 November 2017 08:45:07 UTC