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

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

> On 11 Jul 2019, at 14:07, Christer Holmberg <[e-mail]> 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?
> 
>   Unfortunately I am not able to give information regarding that.
> 
>> 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. 
> 
>    The implementations are based on earlier versions of the draft.
> 
>    And, yes, there is the old saying that one should not deploy a draft before the draft becomes RFC. 
> 
>    But, in this case, the first version of Rifaat's individual draft was submitted in 2014. Then, for whatever reason, it took 3(!) years before it got adopted, and after that we have so far worked on it for two years. How long is one expected to wait for an RFC before deploying???
> 
>     Of course, if something is broken we need to fix it. But, I don't think what you suggest is fixing something that is broken, it is adding new functionality. And, I have no problem with that, as long as it is backward compatible.

I do understand the pain, but I have severe problems of having to adopt to an unknown implemenetation of an early document that wasn’t pushed forward. If you had the resources to do development, why didn’t you spend time pushing the draft forward?

Regardless, it is where we are and we have to find some sort of agreement on how to proceed. I would feel sad of having to support a poor document with too many compromises because of this implementation. Would it really hurt if a working app was not standard-compliant?

/O