Re: [Ace] OAuth-Authz Interop

Mike Jones <> Thu, 10 May 2018 20:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C71412DA11 for <>; Thu, 10 May 2018 13:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LUz_7K8X20ZY for <>; Thu, 10 May 2018 13:00:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6ADEB127869 for <>; Thu, 10 May 2018 13:00:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lryx762WmkVl9ePqV5e5LHD26qZO1I1yW5BvIJ//xyU=; b=IooE/wwNPu9SPxibpOKAxjUx7PNBREVPhVr2FvgkY0+Cc2eoNwnIXOEJOpcVBhma6NCN9H1p7+MGHPVyOjI4Xz1oycMQTI6HX1HHEdHA7vCN66e5JVeF+gHwMAOhCurIj5atQvCPvbG0ACSOVhFmjY3AD7tbkgksrt9JQpmYuN4=
Received: from (2603:10b6:207:1e::30) by (2603:10b6:207:1f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.793.0; Thu, 10 May 2018 20:00:16 +0000
Received: from ([fe80::84a0:cb3c:39ec:1b01]) by ([fe80::84a0:cb3c:39ec:1b01%5]) with mapi id 15.20.0796.000; Thu, 10 May 2018 20:00:16 +0000
From: Mike Jones <>
To: Jim Schaad <>, 'Ludwig Seitz' <>, "" <>
Thread-Topic: [Ace] OAuth-Authz Interop
Thread-Index: AdPmIm8GwlgNR4Z4TAKB3oF5AiJBnQAd1sgAAAhBu4AADchQsABnwz4AAAHS8+A=
Date: Thu, 10 May 2018 20:00:15 +0000
Message-ID: <>
References: <005601d3e622$af427100$0dc75300$> <> <> <> <00cb01d3e891$0158b8d0$040a2a70$>
In-Reply-To: <00cb01d3e891$0158b8d0$040a2a70$>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-10T20:00:13.6128017Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:a::145]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL0PR00MB0340; 7:z7NVatEwhXnxjM4N6nLCl+0rbd0EgJWLHAClLVqEIzfBonc8xpKydVgW+7OtfebG+S4E9yTjovAgP5Ms5tk41GLTi5Zs0FzH4O55zRQyQ7DH4bItYVOJaS2dzJEyjO1kcUkF29o6I0d9M6C2gUXrJVe3dgRkY6uROUkpNWRyzf/vVJiLL9aqwLEJ7h9kz0Exu8Hyc6+eJnbnBB9AM0WOYT9uv/uQz/8xiBkhFmG1Z6UO4Z0bFamJFLvD5U71JKxx; 20:DNKVCI8SyKyxtAxNrRHwlNpfUSTaiTVZwCNfgvkdAXHxrVffddr9GlGNrSI+hvzkboenxEv87s1hj+iUPsB6iZG56C1AhAvY+YMwwkoM0hejUfhMzVP1xMYCjN9RKy4QjciRt9EvY3iVIiSOb62weJsvBkDHNLhp2iQvEIJ48QQ=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:BL0PR00MB0340;
x-ms-traffictypediagnostic: BL0PR00MB0340:
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(166708455590820)(209352067349851)(192374486261705)(60409825278598)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(93006095)(93001095)(10201501046)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BL0PR00MB0340; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0340;
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(39860400002)(346002)(376002)(396003)(69234005)(377424004)(199004)(189003)(13464003)(478600001)(966005)(72206003)(10290500003)(10090500001)(2906002)(229853002)(6436002)(99286004)(25786009)(33656002)(316002)(68736007)(6246003)(53936002)(110136005)(22452003)(86362001)(86612001)(2900100001)(186003)(5660300001)(55016002)(6306002)(8990500004)(74316002)(236005)(9686003)(54896002)(97736004)(21615005)(46003)(3280700002)(486006)(476003)(93886005)(11346002)(446003)(14454004)(2501003)(6506007)(53546011)(102836004)(106356001)(790700001)(6116002)(52396003)(7696005)(76176011)(105586002)(5250100002)(606006)(8936002)(3660700001)(8676002)(81156014)(81166006)(59450400001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0340;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: N8phewkZFliibJ4GdCOughrZr6l+/z8LAKqktoXuML/Q10i2HvIvMNMxPdV3bcWJtHrVd6+UC6UY85v1GdXBhfuCpcNNJzsdU3ioIc/wt9qeInrnGIv+kWX8cyizZM5A6wqXPAq66oPzFDQeEIymMrBRMGneyH0RK3n3e+qXZYA/Y9+94KGbn1r6FaVh2KWV
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292D757C78D626AD8806135F5980BL0PR00MB0292namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 51bcd786-1bde-416d-ebc0-08d5b6b0a61f
X-MS-Exchange-CrossTenant-Network-Message-Id: 51bcd786-1bde-416d-ebc0-08d5b6b0a61f
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 20:00:16.0082 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0340
Archived-At: <>
Subject: Re: [Ace] OAuth-Authz Interop
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 May 2018 20:00:28 -0000

FYI, I haven’t seen any discussion on my review comment that these values should be registered as CWT claims if continued alignment of values is desired.  Certainly the draft hasn’t done that.  Do people see this alignment as valuable?

What values to request for application-specific claims is a related, but different issue.  I could live with using some of the 2-byte space – possibly requesting allocations from 255 down for those that are expected to be commonly used and having the uncommon values be in the 3-byte space.  But the 1-byte space covering the range 0-31 should be reserved for claims that are of truly broad applicability.  Can the draft change the requested assignments for application-specific values to at least move them out of the single-byte 0-31 range?

                                                                -- Mike

From: Jim Schaad <>
Sent: Thursday, May 10, 2018 11:59 AM
To: Mike Jones <>; 'Ludwig Seitz' <>;
Subject: RE: [Ace] OAuth-Authz Interop

Given that we have already started doing interop work and were successful needing to address the number assignment issues does not seem to be a blocking problem.  As long as all of the people doing the interop testing are agreed on what numbers should be there do not seem to be any issues in testing.  The only problem would be if there was a decision to ship products before the assignments were finalized.

In terms of what size of items to use, this is going to be an interesting argument and one that needs to be finalized at some point.  However, it would be just as easy to remove the sentence as to change the values so there are multiple ways of solving this issue.  I don’t know that I agree that application-specific claim keys should be pushed all of the way up to 256, there is always going to be a trade off at this point in terms of what size of key to use vs how often it is believed that the key is going to be used.  If we believe that a huge percentage of usage in the IoT world for CWT items is going to be for this type of authorization and we want to keep alignment to the extent possible then it still makes sense to use the 1 or 2 byte keys for this purpose.  (Side node, it is normal to include all of the bytes encoded in the length so 256 would be a 3 byte value).  This is a trade off that needs to be discussed, but is not currently blocking.


From: Ace <<>> On Behalf Of Mike Jones
Sent: Tuesday, May 8, 2018 10:40 AM
To: Ludwig Seitz <<>>;<>
Subject: Re: [Ace] OAuth-Authz Interop

Before any interop work is done, I suggest that it would be better to first address the significant CBOR number assignment issues I pointed out in my review on October 10, 2017, so that the interop is more likely to occur using number assignments that are less likely to change.  I'm repeating the most important of these comments below, since it was apparently not acted upon.

5.5.5 Mapping parameters to CBOR
It looks to me like these values are intended to align with those registered in the CBOR Web Token (CWT) Claims registry initially populated by  If so, the spec should make this relationship explicit.  However, it would be inappropriate to use the rare single-byte CBOR integer values for application-specific claim keys.  I would suggest that the claim identifiers for client_id through refresh_token and profile start at 256 (a two-byte CBOR value) and go up from there.  In that case, I suspect they could be successfully registered in the CWT Claims registry – which I think you want.  (“cnf” will already be registered by draft-ietf-ace-cwt-proof-of-possession.)

Likewise, please search the review for all instances of the words “register” and “registry” and revised the spec accordingly before any interop work is started.

                                                                -- Mike

-----Original Message-----
From: Ace <<>> On Behalf Of Ludwig Seitz
Sent: Tuesday, May 8, 2018 3:54 AM
Subject: Re: [Ace] OAuth-Authz Interop

On 2018-05-08 08:57, Ludwig Seitz wrote:

> On 2018-05-07 18:44, Jim Schaad wrote:

>> I have been meaning to get this out for a while and have failed.  A

>> doodle poll to setup an interop event for this work is at

>> If you want to participate

>> and none of the times are good please let me know.


>> Things for testing:

>> 1)  DTLS profile w/ shared secret

>> 2)  DTLS profile w/ RPK

>> 3)  OSCORE profile




> Note that I'm in the process of writing a test manual, I'll put it up

> on the WG github as soon as it has some form and structure. Feel free

> to contribute. I'm hoping to have it online by the end of the day.


> /Ludwig



You can find my first draft of the interop manual here:

Note that large parts are still work in progress, but the test plan for the token endpoint should give you a hint as to how I was thinking it could work.

Feel free to propose changes and improvements.



Ludwig Seitz, PhD

Security Lab, RISE SICS

Phone +46(0)70-349 92 51


Ace mailing list<>