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

"Olle E. Johansson" <oej@edvina.net> Thu, 11 July 2019 11:49 UTC

Return-Path: <oej@edvina.net>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB4512011A for <sipcore@ietfa.amsl.com>; Thu, 11 Jul 2019 04:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYOqjEbp7ibG for <sipcore@ietfa.amsl.com>; Thu, 11 Jul 2019 04:49:18 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2AF120045 for <sipcore@ietf.org>; Thu, 11 Jul 2019 04:49:16 -0700 (PDT)
Received: from [192.168.1.69] (static-212-247-19-62.cust.tele2.se [212.247.19.62]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id B1502A40; Thu, 11 Jul 2019 13:49:13 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <C5597D63-1B58-44D0-A2CE-4170CC1BE23E@ericsson.com>
Date: Thu, 11 Jul 2019 13:49:12 +0200
Cc: Olle E Johansson <oej@edvina.net>, "sipcore@ietf.org" <sipcore@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net>
References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <CAGL6epLsP_UfZMAcFLsORrR05Enu-vp=jnkgUFuKSttQm8swAw@mail.gmail.com> <c8d5c42e-ab21-80e8-3189-c8592dd02d3a@alum.mit.edu> <HE1PR07MB3161C55955B2FCED2C0F6A9993F60@HE1PR07MB3161.eurprd07.prod.outlook.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <HE1PR07MB3161D46B4A44FC7E789ADDB893F10@HE1PR07MB3161.eurprd07.prod.outlook.com> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <5bb63c0c-130d-7f69-10b0-1ed1b274cc58@alum.mit.edu> <87AD4BB8-CE77-4FD7-BB72-6643DF513058@ericsson.com> <168b1354-b35b-edee-e5f9-d4ddbecfae40@alum.mit.edu> <607A513F-8616-4777-8B5E-59390E845709@ericsson.com> <b6ca4c79-5a17-10da-3882-20bc8b0e9b98@alum.mit.edu> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <BCFE43BD-86FF-457E-9006-1DA7C8F3F6BE@edvina.net> <C3BFE2FE-0797-4E54-BAD4-B24E32CB183F@ericsson.com> <BD0B9B14-1E35-42C4-BF51-430C7E052145@edvina.net> <C5597D63-1B58-44D0-A2CE-4170CC1BE23E@ericsson.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/QiujKC141EJ5JY2pecrMR3qYe-Q>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2019 11:49:20 -0000


> 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