Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt

> On 11 Jul 2019, at 09:30, Olle E. Johansson <oej@edvina.net> wrote:
> 
> 
> 
>> On 10 Jul 2019, at 17:26, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>> 
>> On 7/9/19 1:45 PM, Christer Holmberg wrote:
>> 
>>> OAuth allows you to re-use the token as many times as you want (until it expires) for the same service. So, for SIP, re-using the token in binding refresh REGISTER requests is fine.
>>> But, you should not re-use a token you got for one "service" (e.g., your registration authentication) with another "service" (e.g., user-to-user authentication for a SIP call). It most likely wouldn't even work.
>> 
>> Is the token somehow bound to the "registration service"? (Whatever that is.)
> In Oauth2 there are two tokens - access token and refresh token. If you add OpenID Connect, there’s an Identity token. Can we please be more
> specific in our discussions? 
> 
> 
>> 
>> ISTM that the token is bound to the parameters from www-authenticate were used in the process of obtaining the token. And so presumably the token should be applicable to any other use that provokes a www-authenticate with the same values of those parameters.
>> 
>> So, if I use a token in REGISTER, and then I do a SUBSCRIBE and get challenged the same way I would expect to use the same token for that. And I might decide to preemptively use the same token in the SUBSCRIBE if it is being sent to the same target.
>> 
>> Based on analogies to Digest, I would expect that after receiving a Bearer challenge and fetching a matching token I would then add that token to a key ring, indexed by some (which?) of the parameters from the www-authenticate. And then in the future for new requests I would look on the key ring for keys (credentials/tokens) suitable for use on this request. (When doing this I might find either Digest or Bearer credentials, or maybe both.)
> 
> The tokens generally, but if I understand it right not always, are JWT structures that contain various data.
Found a draft that specifies an Oauth Access Token JWT profile
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00 <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00>

"The original OAuth 2.0 Authorization Framework [RFC6749 <https://tools.ietf.org/html/rfc6749>]
   specification does not mandate any specific format for access tokens.
   While that remains perfectly appropriate for many important scenario,
   in-market use has shown that many commercial OAuth2 implementations
   elected to issue access tokens using a format that can be parsed and
   validated by resource servers directly, without further authorization
   server involvement.  The approach is particularly common in
   topologies where the authorization server and resource server are not
   co-located, are not ran by the same entity, or are otherwise
   separated by some boundary.  All of the known commercial
   implementations known at this time leverage the JSON Web Tokens(JWT)
   [RFC7519 <https://tools.ietf.org/html/rfc7519>] format.
“

I think we can safely assume that an Access Token is going to be parsable.

/O

> In OpenID connect both the access and identity token are JWTs.
> We can either specify specific claims that  are standardised for various SIP functions or let that be open for the SIP implementors to specify or a combination. 
> 
> I would suggest that a generic specifier meaning “this access token is valid for SIP services” would be a good thing. 
> 
> As a service provider I would like to add authorizations like “this user is authorized for calls to international destinations” or “this user belongs to the support queue”.
> 
> /O
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore