- From: misi via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Dec 2016 15:00:44 +0000
- To: public-webrtc-logs@w3.org
Why I prefer more option #2 and less #3
- We must change API, but the change in option #3 is not as clean as
option #2.
- It is much cleaner if there is a clean demarcation that shows for
the developer
that it is an new or old API implementation that will work or work
not properly with OAuth.
- In the name of "backward compatibility"
- It place concrete that TURN auth information username is
must. What if username will be not used at all in a future STUN auth
method?
- May in the future the credential/token will contain username
in an integrity protected but non-encrypted part of it?
-Option #3 keeps dictionary "username" and "credential" names,
reused, but filed names may not valid in the future and not describe
the values they store, and not explain how the values is used in the
future
- e.g username vs kid
- We need to have on the wire 3 info in case oauth
(kid,mac_key,acces_token). Where mac_key is used identically as
password. For me not self-explanatory and may confusing that we have
only 2 fields in API, and info is also relocated.
- Even the name is confusing for me: credential or credentials?
Sometimes credential contains one a value sometimes a dictionary.
- Disturbing that information that is used to create STUN
HMAC is used once as a simple value of credential, but in other case
the same info is inside a dictionary in lower level in case oauth..
--
GitHub Notification of comment by misi
Please view or discuss this issue at
https://github.com/w3c/webrtc-pc/issues/714#issuecomment-267348435
using your GitHub account
Received on Thursday, 15 December 2016 15:00:50 UTC