W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2016

Re: Issue 714: STUN/TURN OAuth token auth parameter handover

From: Mészáros Mihály <misi@niif.hu>
Date: Mon, 22 Aug 2016 22:56:06 +0200
To: public-webrtc@w3.org
Message-ID: <2afa8dc7-1722-b892-6dca-683fc27027ad@niif.hu>


On 2016.08.19. 11:57, Harald Alvestrand wrote:
> Den 15. aug. 2016 19:46, skrev Bernard Aboba:
>> https://github.com/w3c/webrtc-pc/issues/714
>>
>>   
>>
>> Today we have:
>>
>>   
>>
>> dictionary *RTCIceServer*{
>>
>>      required (DOMString or sequence<DOMString>)|urls|;
>>
>>               DOMString                          |username|
>> <http://w3c.github.io/webrtc-pc/#dom-rtciceserver-username>;
>>
>>               DOMString                          |credential|
>> <http://w3c.github.io/webrtc-pc/#dom-rtciceserver-credential>;
>>
>>               |RTCIceCredentialType|               |credentialType|= "password";
>>
>> };
>>
>>   
>>
>>   
>>
>> enum *RTCIceCredentialType*{
>>
>>      "password
>> <http://w3c.github.io/webrtc-pc/#dom-rtcicecredentialtype-password>",
>>
>>      "token <http://w3c.github.io/webrtc-pc/#dom-rtcicecredentialtype-token>"
>>
>> };
>>
>>   
>>
>> This issue asks how (or if) this can be used to support RFC 7635
>> <https://tools.ietf.org/html/rfc7635> (OAuth 2.0) when credentialType =
>> “token”.
>>
>>   
>>
>> An example of an access token is given in RFC 7635, Appendix B:
>>
>>   
>>
>>          {
>>
>>            "access_token":
>>
>>     "U2FsdGVkX18qJK/kkWmRcnfHglrVTJSpS6yU32kmHmOrfGyI3m1gQj1jRPsr0uBb
>>
>>     HctuycAgsfRX7nJW2BdukGyKMXSiNGNnBzigkAofP6+Z3vkJ1Q5pWbfSRroOkWBn",
>>
>>            "token_type":"pop",
>>
>>            "expires_in":1800,
>>
>>            "kid":"22BIjxU93h/IgwEb",
>>
>>            "key":"v51N62OM65kyMvfTI08O"
>>
>>            "alg":HMAC-SHA-256-128
>>
>>          }
>>
>>   
>>
>> Rather than adding new attributes to RTCIceServer (as proposed in Issue
>> 714), is there a reason why such a token couldn’t be passed in
>> RTCIceServer.credential with RTCIceServer.credentialType = “token”?
>>
> I assume that you would then have the "credential" be the JSON-encoded
> value of that structure?
Yes. It is required, mandatory to have.
>   Or do we just need the "access_token" part?
No access_token it is not enough.
>
> Since PR #714 puts the credential in a DOMString too, I see no
> difference between the two approaches in expressive power or ease of
> access to components of a token.
I am planning to submit a new reviewed PR#714 proposal tomorrow. Please 
review again the PR after it.

I left out from the issue but current PC draft has a sentence that 
needed also to be reviewed.
In 4.3.2 interface definition in setConfiguration

    Ifscheme nameis|turn|or|turns|, and either
    of|server.username|or|server.credential|are omitted, then throw
    an|InvalidAccessError|and abort these steps.


So if the username is empty then according the above an 
InvalidAccessError is thrown.
In case of token, username is empty according your proposal, and all the 
structure is passed as credential, then it cause an issue with this rule.
I propose to extend this step/rule that only apply if credential type is 
password.
> Should the RTCIceCredentialType be extended with the value
> "oauth2-token", or is "token" explicit enough?
I vote for keep it simple, as it is, so leave the name "token", it is 
the same way not exact as it is not exact to call the Long Term 
Credential Auth as "password"..

Misi
Received on Monday, 22 August 2016 20:56:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:49 UTC