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

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

> On 11 Jul 2019, at 09:49, Christer Holmberg <[e-mail]> wrote:
> 
> 
> Hi,
> 
>>>> 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? 
> 
> Good point. When I have been talking about tokens, I refer to Oauth2 tokens. Perhaps we should always indicate that explicitly.
Well, the document talks about both, but let’s name the specific token.
> 
> ...
> 
>> 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. 
> 
> For backward compatibility, we should at least let SIP implementors specify
Maybe, but at least we should write something about the usage of claims and scopes.
I think a base level for this draft is specifying a way to say “this access token is valid for SIP usage” or
“this is also a SIP identity"
> 
>> 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”.
> 
> Such information could also be stored in the user profile in the registrar.
Absolutely. You either use your IDP only for authentication and handle authorization elsewhere or trust the IDP
for authorizations in SIP. That’s up to the implementor.

/O