IETF Logo Mail Archive

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

"Olle E. Johansson" <oej@edvina.net> Thu, 11 July 2019 10:22 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 965261202D6 for <sipcore@ietfa.amsl.com>; Thu, 11 Jul 2019 03:22:32 -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 lj7LaQEXDiCK for <sipcore@ietfa.amsl.com>; Thu, 11 Jul 2019 03:22:30 -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 6AB0B1200D6 for <sipcore@ietf.org>; Thu, 11 Jul 2019 03:22:30 -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 3BA52A40; Thu, 11 Jul 2019 12:22:27 +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: <B45FDA7A-C630-4899-AF67-FD2359C48319@ericsson.com>
Date: Thu, 11 Jul 2019 12:22:25 +0200
Cc: Olle E Johansson <oej@edvina.net>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "sipcore@ietf.org" <sipcore@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF662E15-0AE7-41D3-B564-5BE0AD703B18@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> <C980D7F7-4CED-4363-81AE-199C5A6275B4@edvina.net> <B45FDA7A-C630-4899-AF67-FD2359C48319@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/WWSpInTaVHYFs_xzeZTEc8up5Uk>
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 10:22:33 -0000


> On 11 Jul 2019, at 11:58, 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.
>> Found a draft that specifies an Oauth Access Token JWT profile
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00
>> 
>> "The original OAuth 2.0 Authorization Framework [https://tools.ietf.org/html/rfc6749]
>>  specification does not mandate any specific format for access tokens.
>>  While that remains perfectly appropriate for many important scenario,
>>  in-market use has shown that many commercial OAuth2 implementations
>>  elected to issue access tokens using a format that can be parsed and
>>  validated by resource servers directly, without further authorization
>>  server involvement.  The approach is particularly common in
>>  topologies where the authorization server and resource server are not
>>  co-located, are not ran by the same entity, or are otherwise
>>  separated by some boundary.  All of the known commercial
>>  implementations known at this time leverage the JSON Web Tokens(JWT)
>>  [https://tools.ietf.org/html/rfc7519] format.
>> “
>> 
>> I think we can safely assume that an Access Token is going to be parsable.
> 
> The question is whether we want to mandate JWT, eventhough the statement above probably is correct.

We may want to consult with the Oauth wg to see where they are heading with this and if the break
to backwards compatibility is considered hurtful. As of now, I don’t find anything in our solution
that requires any claim/scope.

Regardless, we can suggest usage of scope and claims in our document.

/O

v2.23.0 | Report a Bug | By Email