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

["Olle E. Johansson" <[e-mail]>]

> On 10 Jul 2019, at 17:26, Paul Kyzivat <[e-mail]> 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. 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