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

This discussion is wandering in many directions. I don't know very much 
(anything?) about OAuth so it is pretty abstract for me. But what is 
becoming clear is that the people discussing this have *many* unstated 
assumptions about how this is to work and how it is to be used. And 
those don't appear to be well aligned with one another.

I've been pushing for more of these assumptions (and implications) to be 
written down in the document. I still want that. But I'm beginning to 
think that the issue is bigger than what is likely to fit into this 
document as it is currently conceived.

I think what may be needed is a framework document. (Perhaps "Framework 
for using OAuth(2?) with SIP", though maybe that isn't quite right. This 
would discuss why this is important, how it relates to the sip 
environment, how it fits into a broader authentication environment, etc.

	Thanks,
	Paul

On 7/11/19 7:49 AM, Olle E. Johansson wrote:
> 
> 
>> On 11 Jul 2019, at 13:25, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>>
>> Hi,
>>
>>>>>>> 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"
>>>>
>>>>    Perhaps we can add some text about scope and claims, but I don't want to mandate usage of specific values, because that
>>>>    may not be backward compatible with existing implementations using JWT.
>>>
>>> We can mandate *if* the access token is a jwt (and there’s an identity token like OpenID Connect).
>>
>>     It may not work with existing implementations that DO use JWT access tokens (not sure whether they use OpenID Connect, though).
> 
> Ok, you are making me interested - what are these implementations?
> When writing a new standard document, should we really be blocked by pre-standard implementations? I would assume that we
> should be inspired by them, learn by their experiences, but not be hindered by them.
> 
>>
>>>> I see interoperability problems if every implementation is using different data structures for stuff like SIP AOR, SIP usage claim
>>>> and maybe a few more that we will come up with as we continue working. Standardizing some of these basic data points in tokens will help interoperability.
>>>
>>> If the access token is a random blob we don’t require any change.
>>>
>>> In addition I think we should change the “sip.token” label to something more specific like “sip.oauth2”.
>>
>>     I think it was me who suggested to use sip.token, but I don't have a strong opinion about it. It was added recently, so existing implementations currently don't use it anyway.
> 
> We have already been confused by discussions about “the token” when in fact there are multiple tokens…
> 
> /O
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 