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

[Christer Holmberg <[e-mail]>]

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).

    >> 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.
 
    Regards,

    Christer