From nobody Fri Mar 1 13:15:20 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C94751311F5; Fri, 1 Mar 2019 13:10:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ekr@rtfm.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147460881.6101.11241393580151638433.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:08 -0800 Archived-At: Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 104 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:22 -0000 Dear Rifaat Shekh-Yusef, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. oauth Session 1 (1:30 requested) Monday, 25 March 2019, Afternoon Session II 1610-1810 Room Name: Athens/Barcelona size: 100 --------------------------------------------- oauth Session 2 (1:30 requested) Thursday, 28 March 2019, Morning Session I 0900-1030 Room Name: Berlin/Brussels size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/oauth.ics Request Information: --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Rifaat Shekh-Yusef Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: acme tls rats Second Priority: ace secevent teep suit core tokbind saag sipcore People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Mar 2 06:26:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CC112785F for ; Sat, 2 Mar 2019 06:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 soeRN5fsS6yS for ; Sat, 2 Mar 2019 06:26:50 -0800 (PST) Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40B7124BAA for ; Sat, 2 Mar 2019 06:26:49 -0800 (PST) Received: by mail-it1-x12a.google.com with SMTP id z131so1215534itf.5 for ; Sat, 02 Mar 2019 06:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lyPw9anWl7+OzTiBii2oz2XnZaQtQQqJOxdmAmZvKWQ=; b=W13/XQCZbYo6Vr5LDQReWyeqRPESEfGYMa5KkennVtCI6Nh5/e/JbGPGMUJ3vzI+hV ucEPt4sSCbUQlV/WOI2MMMnZ5ohwaqG0+T0gm+AUYqxWP3KUbR6BWtjo4MwfgtA/Vq2g K/uvMOhbVoPNtZWfY0Zq1izTWjDxAmZIGjbqM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lyPw9anWl7+OzTiBii2oz2XnZaQtQQqJOxdmAmZvKWQ=; b=ab53YLoU3zrXFpEFZ1e+Ih1yrq+Lgt+YndtQZo8zNPfqsJqcpaMthk/wYUjiAi5unl Z0g7ibfKAkDl6Cb3JGRUQl2of5RPIipZ3qPl2LNnLP+WSMdAz+5bGa0wAtaVEvln3H9D Uexo2PhUYz89Zk4zU5XKB/1yo1jUZZKPQlAZhbwqIvttOHbrwHyBpNCNlgf1cm1u19OV igpEyodhlSYYiauKkv9X117hiEyRXSOYT2L/5Fi4TC+W/FaV45nyFNP4rsggkUf4FOcn px7nFTv2ie5NNKnHOlmoYaCQbj1UBCHGyzMt9rvKSB64cst6mxCe6bRSje4tKrE/iowv WxLQ== X-Gm-Message-State: APjAAAXrkIIgZ36JvFtkWajFGN2QOteuWz0LGDAbficNz3Upcn1mAj9o DKhKgtoE2ODF/T0HRoxfAmVEh7bChww9KOtYxXZWu7VTDyvRo7AQ1pkwdiMwkamIpNqKPueOQ8N 6RhzPQG30B3NWGg8Tbfs= X-Google-Smtp-Source: AHgI3Ib+Fs7VwnXglwEjKjMnuum5WoJSUs9QNUP2TQLS8v7HMlKgwDVagXYTth1l2vfezW4smNL6RVLY/3GAEPD7bW4= X-Received: by 2002:a24:2487:: with SMTP id f129mr6131316ita.124.1551536808671; Sat, 02 Mar 2019 06:26:48 -0800 (PST) MIME-Version: 1.0 References: <9A2A2430-8B1F-4262-96E5-8F5165AAD4F9@iwelcome.com> In-Reply-To: <9A2A2430-8B1F-4262-96E5-8F5165AAD4F9@iwelcome.com> From: Brian Campbell Date: Sat, 2 Mar 2019 07:26:22 -0700 Message-ID: To: Jaap Francke Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000565c1205831d50b9" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 14:26:53 -0000 --000000000000565c1205831d50b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's not uncommon for a resource server (or API or protected resource) to have a client id established with the AS. Typically that's used in the context of the resource server acting as a client (and authenticating with the AS) when calling the AS for access token introspection. Using that id as the audience of an access token is certainly a possibility. But for other client's to know and use the client id of a resource server as the value of =E2=80=98resource=E2=80=99 parameter seems somewhat awkward and un= likely to work particularly well. Also the syntax of the values don't quite match up. n On Wed, Feb 27, 2019 at 12:46 AM Jaap Francke wrote: > Hi all, > > I have some questions/thoughts on the new draft for resource indicators. > I didn=E2=80=99t do an in-depth study but would like to share my thoughts= with you > anyway. > > 1. In this draft, the Resource is identified by =E2=80=98resource=E2=80= =99 parameter. For > example, when the resource is an API, I would expect that API to validate > the access_token at the resource server. The protocol for this would be > based on the API=E2=80=99s client_id, so from that angle using the the cl= ient_id > could be a different way to indicate the intended recipient of the access > token. > > 2. I also think that the =E2=80=98resource=E2=80=99 parameter would be cl= osely related to > the =E2=80=9Caud=E2=80=9D claim specified by the OpenID Connect specifica= tions. I think it > is getting more and more common to use the OIDC-protocol =E2=80=9Con top = of OAuth=E2=80=9D, > so I=E2=80=99m wondering how the resource parameter would relate to that.= The > values of the =E2=80=98aud=E2=80=99 parameter are also client_id=E2=80=99= s. > > Thanks in advance for responding to my views. > Ciao! > > Jaap Francke > > > > On 26 Feb 2019, at 21:00, oauth-request@ietf.org wrote: > > draft-ietf-oauth-resource-indicators-02 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000565c1205831d50b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's not uncommon for a resource serv= er (or API or protected resource) to have a client id established with the = AS. Typically that's used in the context of the resource server acting= as a client (and authenticating with the AS) when calling the AS for acces= s token introspection.=C2=A0 Using that id as the audience of an access tok= en is certainly a possibility. But for other client's to know and use t= he client id of a resource server as the value of =E2=80=98resource=E2=80= =99 parameter seems somewhat awkward and unlikely to work particularly well= . Also the syntax of the values don't quite match up.=C2=A0
n
On W= ed, Feb 27, 2019 at 12:46 AM Jaap Francke <jaap.francke=3D40iwelcome.com@dmarc.ietf.org> wr= ote:
Hi all,

I have some questions/thoughts on the new draft for resource indicator= s.
I didn=E2=80=99t do an in-depth study but would like to share my thoug= hts with you anyway.

1. In this draft, the Resource is identified by =E2=80=98resource=E2= =80=99 parameter. For example, when the resource is an API, I would expect = that API to validate the access_token at the resource server. The protocol = for this would be based on the API=E2=80=99s client_id, so from that angle using the the client_id could be a different way to ind= icate the intended recipient of the access token.

2. I also think that the =E2=80=98resource=E2=80=99 parameter would be= closely related to the =E2=80=9Caud=E2=80=9D claim specified by the OpenID= Connect specifications. I think it is getting more and more common to use = the OIDC-protocol =E2=80=9Con top of OAuth=E2=80=9D, so I=E2=80=99m wonderi= ng how the resource parameter would relate to that. The values of the =E2=80=98au= d=E2=80=99 parameter are also client_id=E2=80=99s.

Thanks in advance for responding to my views.
Ciao!

Jaap Francke



On 26 Feb 2019, at 21:00, oauth-request@ietf.org wrote:

=C2=A0=C2=A0=C2=A0draf= t-ietf-oauth-resource-indicators-02

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000565c1205831d50b9-- From nobody Sat Mar 2 15:28:50 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A21130F03; Sat, 2 Mar 2019 15:28:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef To: X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Cc: rifaat.ietf@gmail.com, Rifaat Shekh-Yusef , iesg-secretary@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Message-ID: <155156932878.27221.6664325541355779686.idtracker@ietfa.amsl.com> Date: Sat, 02 Mar 2019 15:28:48 -0800 Archived-At: Subject: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 23:28:49 -0000 Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-resource-indicators-02 as Proposed Standard on behalf of the OAUTH working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ From nobody Sun Mar 3 18:17:10 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B9F130E78 for ; Sun, 3 Mar 2019 18:17:07 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 tfg1uV2YLitg for ; Sun, 3 Mar 2019 18:17:05 -0800 (PST) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 5CCF4130E09 for ; Sun, 3 Mar 2019 18:17:05 -0800 (PST) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x242Gdks017081; Sun, 3 Mar 2019 21:17:03 -0500 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 3 Mar 2019 21:16:11 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 3 Mar 2019 21:16:56 -0500 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Sun, 3 Mar 2019 21:16:56 -0500 From: Justin Richer To: Jaap Francke CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-resource-indicators-02 Thread-Index: AQHUznCDlavViZgLxU6Xzxv4pDGlC6X7F54A Date: Mon, 4 Mar 2019 02:16:56 +0000 Message-ID: <95435005-B06B-4CB2-987D-CD4A63CE7DE8@mit.edu> References: <9A2A2430-8B1F-4262-96E5-8F5165AAD4F9@iwelcome.com> In-Reply-To: <9A2A2430-8B1F-4262-96E5-8F5165AAD4F9@iwelcome.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_95435005B06B4CB2987DCD4A63CE7DE8mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 02:17:08 -0000 --_000_95435005B06B4CB2987DCD4A63CE7DE8mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmXigJlzIGEgZGlmZmVyZW5jZSBpbiB0aGUgaW50ZW5kZWQgYXVkaWVuY2Ugb2YgdGhlIGFj Y2VzcyB0b2tlbiBpbiBPQXV0aCB2cy4gdGhlIElEIHRva2VuIGluIE9wZW5JRCBDb25uZWN0LiBJ biBPSURDLCB0aGUgSUQgdG9rZW4gaXMgcmVhZCBieSB0aGUgY2xpZW50LCBzbyB0aGUgYXVkaWVu Y2Ugb2YgdGhlIElEIHRva2VuIGlzIHRoZSBjbGllbnTigJlzIElELiBUaGF04oCZcyB0aGUgb25s eSBwYXJ0eSByZWFkaW5nIHRoYXQgdG9rZW4sIGluIHRoZSB1c3VhbCBjYXNlLiBJbiBPQXV0aCwg dGhlIGFjY2VzcyB0b2tlbiBnb2VzIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UgKG9yIHRoZSDi gJxBUEnigJ0gYXMgeW91IHNheSBoZXJlKS4gVGhpcyByZXNvdXJjZSBjb3VsZCBoYXZlIGFuIGlk ZW50aWZpZXIsIGJ1dCBpdOKAmXMgbm90ICpyZWFsbHkqIGEgY2xpZW50IElELCBzaW5jZSB0aGUg cmVzb3VyY2UgaXNu4oCZdCBhIOKAnGNsaWVudOKAnSBpbiB0aGUgT0F1dGggc2Vuc2UuIEFzIEJy aWFuIG1lbnRpb25lZCBpbiBoaXMgZW1haWwsIGR1ZSB0byBzb21lIHVuZm9ydHVuYXRlIG92ZXJs YXAgaW4gZnVuY3Rpb25hbGl0eSwgdGhlIHJlc291cmNlIHNlcnZlciBjb3VsZCBiZSBpc3N1ZWQg aXRzIG93biBJRCBhbmQgc2VjcmV0LCBidXQgdGhlc2UgYXJlIHJlYWxseSAqcmVzb3VyY2UqIElE IGFuZCBub3QgKmNsaWVudCogSUQsIGV2ZW4gdGhvdWdoIHRoZXkgdXNlIHRoZSDigJxjbGllbnRf aWTigJ0gcGFyYW1ldGVyIGZvciBhdXRoZW50aWNhdGlvbi4gVG8gY29uZnVzZSB0aGluZ3MgZXZl biBmdXJ0aGVyLCBtYW55IGltcGxlbWVudGF0aW9ucyB3aWxsIHN0b3JlIHJlc291cmNlIHNlcnZl cnMgYXMg4oCcY2xpZW50c+KAnSB3aXRoIGEgc3BlY2lhbCBmbGFnLiBJdOKAmXMgYSBtYXR0ZXIg b2YgaGluZHNpZ2h0IHRoYXQgd2UgY291bGQgaGF2ZSB1c2VkIGFuIGFic3RyYWN0aW9uIGFib3Zl IHRoZXNlIHR3byB0aGluZ3MsIHNvbWUga2luZCBvZiDigJx0aGluZyB0aGF0IGNhbGxzIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlcuKAnSBvZiB3aGljaCBpbnN0YW5jZXMgd291bGQgaW5jbHVkZSBy ZXNvdXJjZSBzZXJ2ZXJzIGFuZCBjbGllbnRzLg0KDQpTbyBpbiB0aGUgZW5kLCB0aGUgYXVkaWVu Y2Ugb2YgYW4gYWNjZXNzIHRva2VuIGlzIG5vdCBhIGNsaWVudCwgYW5kIHRoZXJlZm9yZSB0aGlz IGZpZWxkIGlzbuKAmXQgYSBjbGllbnQgSUQuIEFkZGl0aW9uYWxseSwgdGhlIElEIGdpdmVuIHRv IGEgcmVzb3VyY2Ugc2VydmVyIHdoaWNoIGNvdWxkIGJlIHVzZWQgaW4gZWl0aGVyIHRoZSDigJxy ZXNvdXJjZeKAnSBhbmQg4oCcYXVkaWVuY2XigJ0gZmllbGQgaXNu4oCZdCBhIGNsaWVudCBJRCBl aXRoZXIgYmVjYXVzZSB0aGUgcmVzb3VyY2UgaXNu4oCZdCBhIGNsaWVudC4NCg0KQW5kIGZpbmFs bHksIHRoZSDigJxyZXNvdXJjZeKAnSBpZGVudGlmaWVyIHVzZWQgaW4gdGhpcyBwYXJhbWV0ZXIg aXMgc29tZXRoaW5nIHRoYXQgaGFzIHRvIGJlIGtub3duIHRvIHRoZSBjbGllbnQsIHNvIHRoYXQg dGhlIGNsaWVudCBjYW4gcmVxdWVzdCBpdCBhdCBydW50aW1lLiBBIHN5c3RlbSBpcyB1bmxpa2Vs eSB0byBwdWJsaXNoIGEgcmVzb3VyY2Ugc2VydmVy4oCZcyBpbnRlcm5hbCBpZGVudGlmaWVyIGlu IHRoaXMgd2F5LCBhbmQgd2lsbCBpbnN0ZWFkIHVzZSBhIGRldmVsb3Blci1mYWNpbmcgbmFtZSBv ciBhIFVSTCBvZiBzb21lIGZsYXZvci4NCg0KSG9wZSB0aGlzIGNsZWFycyB0aGluZ3MgdXAsIGFz IG11Y2ggYXMgaXQgY2FuIGJlLiBJIGFncmVlIHRoYXQgYmV0d2VlbiDigJxyZXNvdXJjZeKAnSwg 4oCcYXVkaWVuY2XigJ0sIGFuZCDigJxzY29wZeKAnSwgcGx1cyB0aGUgVU1BIHN0YW5kYXJk4oCZ cyDigJxwZXJtaXNzaW9u4oCdIHN0cnVjdHVyZSwgdGhpbmdzIGFyZSBtb3JlIHRoYW4gYSBiaXQg bWVzc3kgbm93Lg0KDQrigJQgSnVzdGluDQoNCk9uIEZlYiAyNywgMjAxOSwgYXQgMjo0NiBBTSwg SmFhcCBGcmFuY2tlIDxqYWFwLmZyYW5ja2U9NDBpd2VsY29tZS5jb21AZG1hcmMuaWV0Zi5vcmc8 bWFpbHRvOmphYXAuZnJhbmNrZT00MGl3ZWxjb21lLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3Rl Og0KDQpIaSBhbGwsDQoNCkkgaGF2ZSBzb21lIHF1ZXN0aW9ucy90aG91Z2h0cyBvbiB0aGUgbmV3 IGRyYWZ0IGZvciByZXNvdXJjZSBpbmRpY2F0b3JzLg0KSSBkaWRu4oCZdCBkbyBhbiBpbi1kZXB0 aCBzdHVkeSBidXQgd291bGQgbGlrZSB0byBzaGFyZSBteSB0aG91Z2h0cyB3aXRoIHlvdSBhbnl3 YXkuDQoNCjEuIEluIHRoaXMgZHJhZnQsIHRoZSBSZXNvdXJjZSBpcyBpZGVudGlmaWVkIGJ5IOKA mHJlc291cmNl4oCZIHBhcmFtZXRlci4gRm9yIGV4YW1wbGUsIHdoZW4gdGhlIHJlc291cmNlIGlz IGFuIEFQSSwgSSB3b3VsZCBleHBlY3QgdGhhdCBBUEkgdG8gdmFsaWRhdGUgdGhlIGFjY2Vzc190 b2tlbiBhdCB0aGUgcmVzb3VyY2Ugc2VydmVyLiBUaGUgcHJvdG9jb2wgZm9yIHRoaXMgd291bGQg YmUgYmFzZWQgb24gdGhlIEFQSeKAmXMgY2xpZW50X2lkLCBzbyBmcm9tIHRoYXQgYW5nbGUgdXNp bmcgdGhlIHRoZSBjbGllbnRfaWQgY291bGQgYmUgYSBkaWZmZXJlbnQgd2F5IHRvIGluZGljYXRl IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhlIGFjY2VzcyB0b2tlbi4NCg0KMi4gSSBhbHNv IHRoaW5rIHRoYXQgdGhlIOKAmHJlc291cmNl4oCZIHBhcmFtZXRlciB3b3VsZCBiZSBjbG9zZWx5 IHJlbGF0ZWQgdG8gdGhlIOKAnGF1ZOKAnSBjbGFpbSBzcGVjaWZpZWQgYnkgdGhlIE9wZW5JRCBD b25uZWN0IHNwZWNpZmljYXRpb25zLiBJIHRoaW5rIGl0IGlzIGdldHRpbmcgbW9yZSBhbmQgbW9y ZSBjb21tb24gdG8gdXNlIHRoZSBPSURDLXByb3RvY29sIOKAnG9uIHRvcCBvZiBPQXV0aOKAnSwg c28gSeKAmW0gd29uZGVyaW5nIGhvdyB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIHdvdWxkIHJlbGF0 ZSB0byB0aGF0LiBUaGUgdmFsdWVzIG9mIHRoZSDigJhhdWTigJkgcGFyYW1ldGVyIGFyZSBhbHNv IGNsaWVudF9pZOKAmXMuDQoNClRoYW5rcyBpbiBhZHZhbmNlIGZvciByZXNwb25kaW5nIHRvIG15 IHZpZXdzLg0KQ2lhbyENCg0KSmFhcCBGcmFuY2tlDQoNCg0KDQpPbiAyNiBGZWIgMjAxOSwgYXQg MjE6MDAsIG9hdXRoLXJlcXVlc3RAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLXJlcXVlc3RAaWV0Zi5v cmc+IHdyb3RlOg0KDQogICBkcmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDIN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_95435005B06B4CB2987DCD4A63CE7DE8mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: <250449AF9C03C74F82F97B3A502A3E81@exchange.mit.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoZXJl4oCZcyBhIGRpZmZlcmVuY2UgaW4gdGhl IGludGVuZGVkIGF1ZGllbmNlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gaW4gT0F1dGggdnMuIHRoZSBJ RCB0b2tlbiBpbiBPcGVuSUQgQ29ubmVjdC4gSW4gT0lEQywgdGhlIElEIHRva2VuIGlzIHJlYWQg YnkgdGhlIGNsaWVudCwgc28gdGhlIGF1ZGllbmNlIG9mIHRoZSBJRCB0b2tlbiBpcyB0aGUgY2xp ZW504oCZcyBJRC4gVGhhdOKAmXMgdGhlIG9ubHkgcGFydHkgcmVhZGluZyB0aGF0IHRva2VuLCBp biB0aGUNCiB1c3VhbCBjYXNlLiBJbiBPQXV0aCwgdGhlIGFjY2VzcyB0b2tlbiBnb2VzIHRvIHRo ZSBwcm90ZWN0ZWQgcmVzb3VyY2UgKG9yIHRoZSDigJxBUEnigJ0gYXMgeW91IHNheSBoZXJlKS4g VGhpcyByZXNvdXJjZSBjb3VsZCBoYXZlIGFuIGlkZW50aWZpZXIsIGJ1dCBpdOKAmXMgbm90ICpy ZWFsbHkqIGEgY2xpZW50IElELCBzaW5jZSB0aGUgcmVzb3VyY2UgaXNu4oCZdCBhIOKAnGNsaWVu dOKAnSBpbiB0aGUgT0F1dGggc2Vuc2UuIEFzIEJyaWFuIG1lbnRpb25lZCBpbiBoaXMNCiBlbWFp bCwgZHVlIHRvIHNvbWUgdW5mb3J0dW5hdGUgb3ZlcmxhcCBpbiBmdW5jdGlvbmFsaXR5LCB0aGUg cmVzb3VyY2Ugc2VydmVyIGNvdWxkIGJlIGlzc3VlZCBpdHMgb3duIElEIGFuZCBzZWNyZXQsIGJ1 dCB0aGVzZSBhcmUgcmVhbGx5ICpyZXNvdXJjZSogSUQgYW5kIG5vdCAqY2xpZW50KiBJRCwgZXZl biB0aG91Z2ggdGhleSB1c2UgdGhlIOKAnGNsaWVudF9pZOKAnSBwYXJhbWV0ZXIgZm9yIGF1dGhl bnRpY2F0aW9uLiBUbyBjb25mdXNlIHRoaW5ncw0KIGV2ZW4gZnVydGhlciwgbWFueSBpbXBsZW1l bnRhdGlvbnMgd2lsbCBzdG9yZSByZXNvdXJjZSBzZXJ2ZXJzIGFzIOKAnGNsaWVudHPigJ0gd2l0 aCBhIHNwZWNpYWwgZmxhZy4gSXTigJlzIGEgbWF0dGVyIG9mIGhpbmRzaWdodCB0aGF0IHdlIGNv dWxkIGhhdmUgdXNlZCBhbiBhYnN0cmFjdGlvbiBhYm92ZSB0aGVzZSB0d28gdGhpbmdzLCBzb21l IGtpbmQgb2Yg4oCcdGhpbmcgdGhhdCBjYWxscyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0g b2Ygd2hpY2ggaW5zdGFuY2VzDQogd291bGQgaW5jbHVkZSByZXNvdXJjZSBzZXJ2ZXJzIGFuZCBj bGllbnRzLiZuYnNwOw0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+U28gaW4gdGhlIGVuZCwgdGhlIGF1ZGllbmNlIG9mIGFuIGFjY2VzcyB0b2tlbiBp cyBub3QgYSBjbGllbnQsIGFuZCB0aGVyZWZvcmUgdGhpcyBmaWVsZCBpc27igJl0IGEgY2xpZW50 IElELiBBZGRpdGlvbmFsbHksIHRoZSBJRCBnaXZlbiB0byBhIHJlc291cmNlIHNlcnZlciB3aGlj aCBjb3VsZCBiZSB1c2VkIGluIGVpdGhlciB0aGUg4oCccmVzb3VyY2XigJ0gYW5kIOKAnGF1ZGll bmNl4oCdIGZpZWxkIGlzbuKAmXQgYSBjbGllbnQgSUQgZWl0aGVyDQogYmVjYXVzZSB0aGUgcmVz b3VyY2UgaXNu4oCZdCBhIGNsaWVudC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFuZCBmaW5hbGx5LCB0aGUg4oCccmVzb3Vy Y2XigJ0gaWRlbnRpZmllciB1c2VkIGluIHRoaXMgcGFyYW1ldGVyIGlzIHNvbWV0aGluZyB0aGF0 IGhhcyB0byBiZSBrbm93biB0byB0aGUgY2xpZW50LCBzbyB0aGF0IHRoZSBjbGllbnQgY2FuIHJl cXVlc3QgaXQgYXQgcnVudGltZS4gQSBzeXN0ZW0gaXMgdW5saWtlbHkgdG8gcHVibGlzaCBhIHJl c291cmNlIHNlcnZlcuKAmXMgaW50ZXJuYWwgaWRlbnRpZmllciBpbiB0aGlzIHdheSwgYW5kDQog d2lsbCBpbnN0ZWFkIHVzZSBhIGRldmVsb3Blci1mYWNpbmcgbmFtZSBvciBhIFVSTCBvZiBzb21l IGZsYXZvci48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkhvcGUgdGhpcyBjbGVhcnMgdGhpbmdzIHVwLCBhcyBtdWNoIGFzIGl0IGNhbiBi ZS4gSSBhZ3JlZSB0aGF0IGJldHdlZW4g4oCccmVzb3VyY2XigJ0sIOKAnGF1ZGllbmNl4oCdLCBh bmQg4oCcc2NvcGXigJ0sIHBsdXMgdGhlIFVNQSBzdGFuZGFyZOKAmXMg4oCccGVybWlzc2lvbuKA nSBzdHJ1Y3R1cmUsIHRoaW5ncyBhcmUgbW9yZSB0aGFuIGEgYml0IG1lc3N5IG5vdy48YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEZlYiAyNywg MjAxOSwgYXQgMjo0NiBBTSwgSmFhcCBGcmFuY2tlICZsdDs8YSBocmVmPSJtYWlsdG86amFhcC5m cmFuY2tlPTQwaXdlbGNvbWUuY29tQGRtYXJjLmlldGYub3JnIiBjbGFzcz0iIj5qYWFwLmZyYW5j a2U9NDBpd2VsY29tZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxi ciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpIaSBhbGwsDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGhhdmUgc29t ZSBxdWVzdGlvbnMvdGhvdWdodHMgb24gdGhlIG5ldyBkcmFmdCBmb3IgcmVzb3VyY2UgaW5kaWNh dG9ycy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBkaWRu4oCZdCBkbyBhbiBpbi1kZXB0aCBzdHVk eSBidXQgd291bGQgbGlrZSB0byBzaGFyZSBteSB0aG91Z2h0cyB3aXRoIHlvdSBhbnl3YXkuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4x LiBJbiB0aGlzIGRyYWZ0LCB0aGUgUmVzb3VyY2UgaXMgaWRlbnRpZmllZCBieSDigJhyZXNvdXJj ZeKAmSBwYXJhbWV0ZXIuIEZvciBleGFtcGxlLCB3aGVuIHRoZSByZXNvdXJjZSBpcyBhbiBBUEks IEkgd291bGQgZXhwZWN0IHRoYXQgQVBJIHRvIHZhbGlkYXRlIHRoZSBhY2Nlc3NfdG9rZW4gYXQg dGhlIHJlc291cmNlIHNlcnZlci4gVGhlIHByb3RvY29sIGZvciB0aGlzIHdvdWxkIGJlIGJhc2Vk IG9uIHRoZSBBUEnigJlzIGNsaWVudF9pZCwNCiBzbyBmcm9tIHRoYXQgYW5nbGUgdXNpbmcgdGhl IHRoZSBjbGllbnRfaWQgY291bGQgYmUgYSBkaWZmZXJlbnQgd2F5IHRvIGluZGljYXRlIHRoZSBp bnRlbmRlZCByZWNpcGllbnQgb2YgdGhlIGFjY2VzcyB0b2tlbi48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjIuIEkgYWxzbyB0aGluayB0 aGF0IHRoZSDigJhyZXNvdXJjZeKAmSBwYXJhbWV0ZXIgd291bGQgYmUgY2xvc2VseSByZWxhdGVk IHRvIHRoZSDigJxhdWTigJ0gY2xhaW0gc3BlY2lmaWVkIGJ5IHRoZSBPcGVuSUQgQ29ubmVjdCBz cGVjaWZpY2F0aW9ucy4gSSB0aGluayBpdCBpcyBnZXR0aW5nIG1vcmUgYW5kIG1vcmUgY29tbW9u IHRvIHVzZSB0aGUgT0lEQy1wcm90b2NvbCDigJxvbiB0b3Agb2YgT0F1dGjigJ0sIHNvIEnigJlt IHdvbmRlcmluZyBob3cNCiB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIHdvdWxkIHJlbGF0ZSB0byB0 aGF0LiBUaGUgdmFsdWVzIG9mIHRoZSDigJhhdWTigJkgcGFyYW1ldGVyIGFyZSBhbHNvIGNsaWVu dF9pZOKAmXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5UaGFua3MgaW4gYWR2YW5jZSBmb3IgcmVzcG9uZGluZyB0byBteSB2aWV3cy48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2lhbyE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkphYXAgRnJhbmNrZTwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMjYgRmViIDIwMTksIGF0IDIxOjAwLCA8YSBocmVmPSJt YWlsdG86b2F1dGgtcmVxdWVzdEBpZXRmLm9yZyIgY2xhc3M9IiI+DQpvYXV0aC1yZXF1ZXN0QGll dGYub3JnPC9hPiB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi PiZuYnNwOyZuYnNwOyZuYnNwO2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0w Mjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJl Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBjbGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIg Y2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_95435005B06B4CB2987DCD4A63CE7DE8mitedu_-- From nobody Mon Mar 4 10:15:37 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6E7131016 for ; Mon, 4 Mar 2019 10:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 zfdOoiWmqniq for ; Mon, 4 Mar 2019 10:15:29 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A411D130F62 for ; Mon, 4 Mar 2019 10:15:28 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id z20so5155730ljj.10 for ; Mon, 04 Mar 2019 10:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KZ5B8vfix/nYI7VsP0s6wPTZHxmyiNY02drN7ber3g8=; b=dozmEAEnqGBmLOT0Swq68NSvZ0gtwfDSn9oiYJRo0aNubpTusuB/NfUb3JJdQQyAhD 5ogRRYGks9MXZ9GyuugIt5sEfeFvmfb5Y5F06Cn7yASozecTx8+fZKsLUo30w4X1Ouu7 UrQ9x+XLzcEnhu7WmyzW4+2Hy3w3fFNoQeCG+ysKXyBQPkQnCi92PD+kfdvZY6OAqcmw T91tP5pT3t72Qz80kxVsu/az06eGyJgU64SRfhYnCtCn8cXu1F6XNLg/YPTKVeE2Ngj8 W8YBcHVDHVWlmUDwdG46qI3iL6FeuGZ79H+fuZ/X6+b1ZqRWM8Qm5wvIDEBX8M5afCQP TFxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KZ5B8vfix/nYI7VsP0s6wPTZHxmyiNY02drN7ber3g8=; b=FkhPLJUyYcIjy7iR5mQpoLuYDOtHP3gMGw3gzA8U85RN0zXur/lSTDEvrcLAnD+ySD 01TjDYsWk+b3TAdj2EaaHOpcGByu44kN2xtdWslXKcsygmdciOhkmgkhaU+sbGoff+Xq Dsp0YECxHVgcMWF6OM9pQLkIuJxJZE1HM7gcFlV2sfXcaDKqI6U1sJhbw5sEZrG2slpq 9IODoRDaUDteOtGFQwS9X+Paow4wmr0xZNwdAwETna3jD6wREEcvBN3wasYL8Eh5lG96 q6kyiPVGIkxzb/6Vc3O+EfFmZfBPzu0BBgDv3HODsCU9v3dg688x93FC0brtc/xR5j+C xBfA== X-Gm-Message-State: APjAAAUPrGjjGOtyuoC/nSSo4tRhoT6iGVCQdXKamb5YiJr6g1D0DRS1 C1SJAIITOmdnSc6au9mSvSS60Oubho2lvEutWVy5QA== X-Google-Smtp-Source: APXvYqyFsiJcd5FP98wtVpYinhcwO5li/WB8+gD3fBiLbIB3FXAVS0fQy9yVOWx1zBwTEA6joYas/hlUyvIGgRRaUcY= X-Received: by 2002:a2e:8084:: with SMTP id i4mr11173129ljg.44.1551723326483; Mon, 04 Mar 2019 10:15:26 -0800 (PST) MIME-Version: 1.0 References: <9A2A2430-8B1F-4262-96E5-8F5165AAD4F9@iwelcome.com> <95435005-B06B-4CB2-987D-CD4A63CE7DE8@mit.edu> In-Reply-To: <95435005-B06B-4CB2-987D-CD4A63CE7DE8@mit.edu> From: Vittorio Bertocci Date: Mon, 4 Mar 2019 10:15:15 -0800 Message-ID: To: Justin Richer Cc: Jaap Francke , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000aa4612058348bd90" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 18:15:33 -0000 --000000000000aa4612058348bd90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To add some color, here there's a concrete scenario where many of those concepts come together (or collide, if you prefer). Azure AD implements am early draft of token exchange, largely for implementing a cloud friendly version of kerberos constrained delegation- say a native client calls a mid tier API, and the mid tier API turns around and calls a backend API flowing the identity of the user. In order to do so, the mid-tier API performs a request to the authorization server asking for the scopes the backend API requires, and presenting as a grant the access token it received from the native client. The AS verifies that the resource owner previously granted consent (as there is no opportunity to show any UX). Here's the relevant part: *the AS also verifies whether the audience in the access token (in whatever way it is expressed) corresponds to the client ID of the requestor, to prevent MITM attacks to gain an avenue for minting new tokens from arbitrarily captured ATs*. In other words, the AS needs a mechanism to know that the resource indicator for the mid tier API and the client ID used by the app implementing that API to ask for new tokens are in fact pointing to the same entity. The AS can always do this on its own, without relying on any standard guidance, and provide its own mechanism to associate API resource indicators with client IDs - but this scenario does suggest that it would be handy to be able to use the mid tier API clientID as an identifier in the request from the native client to get the bootstrap token. I agree that doing so today is super confusing, as the developer would use something with "client" in its name to indicate a resource. To me this is a consequence of expressing everything in term of clients, which comes from the OAuth2 heritage of those flows, but doesn't provide a way of modeling the frequent occurrence in which an application legitimately plays both the resource (in the most general sense, including web sites) and the client role. On Sun, Mar 3, 2019 at 6:17 PM Justin Richer wrote: > There=E2=80=99s a difference in the intended audience of the access token= in OAuth > vs. the ID token in OpenID Connect. In OIDC, the ID token is read by the > client, so the audience of the ID token is the client=E2=80=99s ID. That= =E2=80=99s the only > party reading that token, in the usual case. In OAuth, the access token > goes to the protected resource (or the =E2=80=9CAPI=E2=80=9D as you say h= ere). This > resource could have an identifier, but it=E2=80=99s not *really* a client= ID, since > the resource isn=E2=80=99t a =E2=80=9Cclient=E2=80=9D in the OAuth sense.= As Brian mentioned in his > email, due to some unfortunate overlap in functionality, the resource > server could be issued its own ID and secret, but these are really > *resource* ID and not *client* ID, even though they use the =E2=80=9Cclie= nt_id=E2=80=9D > parameter for authentication. To confuse things even further, many > implementations will store resource servers as =E2=80=9Cclients=E2=80=9D = with a special > flag. It=E2=80=99s a matter of hindsight that we could have used an abstr= action > above these two things, some kind of =E2=80=9Cthing that calls the author= ization > server=E2=80=9D of which instances would include resource servers and cli= ents. > > So in the end, the audience of an access token is not a client, and > therefore this field isn=E2=80=99t a client ID. Additionally, the ID give= n to a > resource server which could be used in either the =E2=80=9Cresource=E2=80= =9D and =E2=80=9Caudience=E2=80=9D > field isn=E2=80=99t a client ID either because the resource isn=E2=80=99t= a client. > > And finally, the =E2=80=9Cresource=E2=80=9D identifier used in this param= eter is something > that has to be known to the client, so that the client can request it at > runtime. A system is unlikely to publish a resource server=E2=80=99s inte= rnal > identifier in this way, and will instead use a developer-facing name or a > URL of some flavor. > > Hope this clears things up, as much as it can be. I agree that between > =E2=80=9Cresource=E2=80=9D, =E2=80=9Caudience=E2=80=9D, and =E2=80=9Cscop= e=E2=80=9D, plus the UMA standard=E2=80=99s =E2=80=9Cpermission=E2=80=9D > structure, things are more than a bit messy now. > > =E2=80=94 Justin > > On Feb 27, 2019, at 2:46 AM, Jaap Francke < > jaap.francke=3D40iwelcome.com@dmarc.ietf.org> wrote: > > Hi all, > > I have some questions/thoughts on the new draft for resource indicators. > I didn=E2=80=99t do an in-depth study but would like to share my thoughts= with you > anyway. > > 1. In this draft, the Resource is identified by =E2=80=98resource=E2=80= =99 parameter. For > example, when the resource is an API, I would expect that API to validate > the access_token at the resource server. The protocol for this would be > based on the API=E2=80=99s client_id, so from that angle using the the cl= ient_id > could be a different way to indicate the intended recipient of the access > token. > > 2. I also think that the =E2=80=98resource=E2=80=99 parameter would be cl= osely related to > the =E2=80=9Caud=E2=80=9D claim specified by the OpenID Connect specifica= tions. I think it > is getting more and more common to use the OIDC-protocol =E2=80=9Con top = of OAuth=E2=80=9D, > so I=E2=80=99m wondering how the resource parameter would relate to that.= The > values of the =E2=80=98aud=E2=80=99 parameter are also client_id=E2=80=99= s. > > Thanks in advance for responding to my views. > Ciao! > > Jaap Francke > > > > On 26 Feb 2019, at 21:00, oauth-request@ietf.org wrote: > > draft-ietf-oauth-resource-indicators-02 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000aa4612058348bd90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To add some color, here there's a concrete scenario wh= ere many of those concepts come together (or collide, if you prefer).
A= zure AD implements am early draft of token exchange, largely for implementi= ng a cloud friendly version of kerberos constrained delegation- say a nativ= e client calls a mid tier API, and the mid tier API turns around and calls = a backend API flowing the identity of the user.
In order to do so= , the mid-tier API performs a request to the authorization server asking fo= r the scopes the backend API requires, and presenting as a grant the access= token it received from the native client. The AS verifies that the resourc= e owner previously granted consent (as there is no opportunity to show any = UX). Here's the relevant part: the AS also verifies whether the audi= ence in the access token (in whatever way it is expressed) corresponds to t= he client ID of the requestor, to prevent MITM attacks to gain an avenue fo= r minting new tokens from arbitrarily captured ATs. In other words, the= AS needs a mechanism to know that the resource indicator for the mid tier = API and the client ID used by the app implementing that API to ask for new = tokens are in fact pointing to the same entity.
The AS can always= do this on its own, without relying on any standard guidance, and provide = its own mechanism to associate API resource indicators with client IDs - bu= t this scenario does suggest that it would be handy to be able to use the m= id tier API clientID as an identifier in the request from the native client= to get the bootstrap token.
I agree that doing so today is super= confusing, as the developer would use something with "client" in= its name to indicate a resource. To me this is a consequence of expressing= everything in term of clients, which comes from the OAuth2 heritage of tho= se flows, but doesn't provide a way of modeling the frequent occurrence= in which an application legitimately plays both the resource (in the most = general sense, including web sites) and the client role.=C2=A0
<= br>
On Sun,= Mar 3, 2019 at 6:17 PM Justin Richer <jricher@mit.edu> wrote:
There=E2=80=99s a difference in the intended audience of the access token i= n OAuth vs. the ID token in OpenID Connect. In OIDC, the ID token is read b= y the client, so the audience of the ID token is the client=E2=80=99s ID. T= hat=E2=80=99s the only party reading that token, in the usual case. In OAuth, the access token goes to the protected resource (or = the =E2=80=9CAPI=E2=80=9D as you say here). This resource could have an ide= ntifier, but it=E2=80=99s not *really* a client ID, since the resource isn= =E2=80=99t a =E2=80=9Cclient=E2=80=9D in the OAuth sense. As Brian mentione= d in his email, due to some unfortunate overlap in functionality, the resource serv= er could be issued its own ID and secret, but these are really *resource* I= D and not *client* ID, even though they use the =E2=80=9Cclient_id=E2=80=9D= parameter for authentication. To confuse things even further, many implementations will store resource servers as =E2=80= =9Cclients=E2=80=9D with a special flag. It=E2=80=99s a matter of hindsight= that we could have used an abstraction above these two things, some kind o= f =E2=80=9Cthing that calls the authorization server=E2=80=9D of which inst= ances would include resource servers and clients.=C2=A0

So in the end, the audience of an access token is not a client, and th= erefore this field isn=E2=80=99t a client ID. Additionally, the ID given to= a resource server which could be used in either the =E2=80=9Cresource=E2= =80=9D and =E2=80=9Caudience=E2=80=9D field isn=E2=80=99t a client ID eithe= r because the resource isn=E2=80=99t a client.=C2=A0

And finally, the =E2=80=9Cresource=E2=80=9D identifier used in this pa= rameter is something that has to be known to the client, so that the client= can request it at runtime. A system is unlikely to publish a resource serv= er=E2=80=99s internal identifier in this way, and will instead use a developer-facing name or a URL of some flavor.

Hope this clears things up, as much as it can be. I agree that between= =E2=80=9Cresource=E2=80=9D, =E2=80=9Caudience=E2=80=9D, and =E2=80=9Cscope= =E2=80=9D, plus the UMA standard=E2=80=99s =E2=80=9Cpermission=E2=80=9D str= ucture, things are more than a bit messy now.

=E2=80=94 Justin

On Feb 27, 2019, at 2:46 AM, Jaap Francke <jaap.francke=3D40= iwelcome.com@dmarc.ietf.org> wrote:

Hi all,

I have some questions/thoughts on the new draft for resource indicator= s.
I didn=E2=80=99t do an in-depth study but would like to share my thoug= hts with you anyway.

1. In this draft, the Resource is identified by =E2=80=98resource=E2= =80=99 parameter. For example, when the resource is an API, I would expect = that API to validate the access_token at the resource server. The protocol = for this would be based on the API=E2=80=99s client_id, so from that angle using the the client_id could be a different way to ind= icate the intended recipient of the access token.

2. I also think that the =E2=80=98resource=E2=80=99 parameter would be= closely related to the =E2=80=9Caud=E2=80=9D claim specified by the OpenID= Connect specifications. I think it is getting more and more common to use = the OIDC-protocol =E2=80=9Con top of OAuth=E2=80=9D, so I=E2=80=99m wonderi= ng how the resource parameter would relate to that. The values of the =E2=80=98au= d=E2=80=99 parameter are also client_id=E2=80=99s.

Thanks in advance for responding to my views.
Ciao!

Jaap Francke



On 26 Feb 2019, at 21:00, oauth-request@ietf.org wrote:

=C2=A0=C2=A0=C2=A0draf= t-ietf-oauth-resource-indicators-02

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000aa4612058348bd90-- From nobody Mon Mar 4 13:38:44 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4207B12D7EA for ; Mon, 4 Mar 2019 13:38:43 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8zjo1zOIPonU for ; Mon, 4 Mar 2019 13:38:40 -0800 (PST) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 D6049130E78 for ; Mon, 4 Mar 2019 13:38:36 -0800 (PST) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x24LcCrq017591; Mon, 4 Mar 2019 16:38:33 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 4 Mar 2019 16:37:41 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 4 Mar 2019 16:38:02 -0500 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Mon, 4 Mar 2019 16:38:02 -0500 From: Justin Richer To: Vittorio Bertocci CC: Jaap Francke , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-resource-indicators-02 Thread-Index: AQHUznCDlavViZgLxU6Xzxv4pDGlC6X7F54AgAELwICAADioAA== Date: Mon, 4 Mar 2019 21:38:02 +0000 Message-ID: References: <9A2A2430-8B1F-4262-96E5-8F5165AAD4F9@iwelcome.com> <95435005-B06B-4CB2-987D-CD4A63CE7DE8@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: multipart/alternative; boundary="_000_F3A5CCAD78214723A37FFC64333479B0mitedu_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-resource-indicators-02 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:38:43 -0000 --_000_F3A5CCAD78214723A37FFC64333479B0mitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnV0IGluIHRoaXMgc2NlbmFyaW8sIHRoZSDigJxhdWRpZW5jZeKAnSBvZiB0aGUgdG9rZW4gaXMg dGhlIHJlc291cmNlIHNlcnZlcuKAmXMgSUQsIHJpZ2h0PyBBbmQgbm90IHRoZSBvcmlnaW5hbCBj bGllbnTigJlzIGNsaWVudCBpZC4gVGhpcyBpcyBhIGNhc2Ugd2hlcmUgdGhlIFJTIGlzIDphbHNv OiBhIGNsaWVudCwgYmVjYXVzZSBvZiB0aGUgdG9rZW4gZXhjaGFuZ2UgYml0LCBidXQgeW91IGNh buKAmXQgc2F5IHRoZSBhdWRpZW5jZSBpcyBhbHdheXMgZ29pbmcgdG8gYmUgYSBjbGllbnQgSUQg YmVjYXVzZSBtb3N0IHJlc291cmNlIHNlcnZlcnMgb3V0IHRoZXJlIGFyZW7igJl0IGFsc28gZ29p bmcgdG8gYmUgY2xpZW50cyBpbiB0aGVpciBvd24gcmlnaHQuDQoNCuKAlCBKdXN0aW4NCg0KT24g TWFyIDQsIDIwMTksIGF0IDE6MTUgUE0sIFZpdHRvcmlvIEJlcnRvY2NpIDxWaXR0b3Jpb0BhdXRo MC5jb208bWFpbHRvOlZpdHRvcmlvQGF1dGgwLmNvbT4+IHdyb3RlOg0KDQpUbyBhZGQgc29tZSBj b2xvciwgaGVyZSB0aGVyZSdzIGEgY29uY3JldGUgc2NlbmFyaW8gd2hlcmUgbWFueSBvZiB0aG9z ZSBjb25jZXB0cyBjb21lIHRvZ2V0aGVyIChvciBjb2xsaWRlLCBpZiB5b3UgcHJlZmVyKS4NCkF6 dXJlIEFEIGltcGxlbWVudHMgYW0gZWFybHkgZHJhZnQgb2YgdG9rZW4gZXhjaGFuZ2UsIGxhcmdl bHkgZm9yIGltcGxlbWVudGluZyBhIGNsb3VkIGZyaWVuZGx5IHZlcnNpb24gb2Yga2VyYmVyb3Mg Y29uc3RyYWluZWQgZGVsZWdhdGlvbi0gc2F5IGEgbmF0aXZlIGNsaWVudCBjYWxscyBhIG1pZCB0 aWVyIEFQSSwgYW5kIHRoZSBtaWQgdGllciBBUEkgdHVybnMgYXJvdW5kIGFuZCBjYWxscyBhIGJh Y2tlbmQgQVBJIGZsb3dpbmcgdGhlIGlkZW50aXR5IG9mIHRoZSB1c2VyLg0KSW4gb3JkZXIgdG8g ZG8gc28sIHRoZSBtaWQtdGllciBBUEkgcGVyZm9ybXMgYSByZXF1ZXN0IHRvIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBhc2tpbmcgZm9yIHRoZSBzY29wZXMgdGhlIGJhY2tlbmQgQVBJIHJlcXVp cmVzLCBhbmQgcHJlc2VudGluZyBhcyBhIGdyYW50IHRoZSBhY2Nlc3MgdG9rZW4gaXQgcmVjZWl2 ZWQgZnJvbSB0aGUgbmF0aXZlIGNsaWVudC4gVGhlIEFTIHZlcmlmaWVzIHRoYXQgdGhlIHJlc291 cmNlIG93bmVyIHByZXZpb3VzbHkgZ3JhbnRlZCBjb25zZW50IChhcyB0aGVyZSBpcyBubyBvcHBv cnR1bml0eSB0byBzaG93IGFueSBVWCkuIEhlcmUncyB0aGUgcmVsZXZhbnQgcGFydDogdGhlIEFT IGFsc28gdmVyaWZpZXMgd2hldGhlciB0aGUgYXVkaWVuY2UgaW4gdGhlIGFjY2VzcyB0b2tlbiAo aW4gd2hhdGV2ZXIgd2F5IGl0IGlzIGV4cHJlc3NlZCkgY29ycmVzcG9uZHMgdG8gdGhlIGNsaWVu dCBJRCBvZiB0aGUgcmVxdWVzdG9yLCB0byBwcmV2ZW50IE1JVE0gYXR0YWNrcyB0byBnYWluIGFu IGF2ZW51ZSBmb3IgbWludGluZyBuZXcgdG9rZW5zIGZyb20gYXJiaXRyYXJpbHkgY2FwdHVyZWQg QVRzLiBJbiBvdGhlciB3b3JkcywgdGhlIEFTIG5lZWRzIGEgbWVjaGFuaXNtIHRvIGtub3cgdGhh dCB0aGUgcmVzb3VyY2UgaW5kaWNhdG9yIGZvciB0aGUgbWlkIHRpZXIgQVBJIGFuZCB0aGUgY2xp ZW50IElEIHVzZWQgYnkgdGhlIGFwcCBpbXBsZW1lbnRpbmcgdGhhdCBBUEkgdG8gYXNrIGZvciBu ZXcgdG9rZW5zIGFyZSBpbiBmYWN0IHBvaW50aW5nIHRvIHRoZSBzYW1lIGVudGl0eS4NClRoZSBB UyBjYW4gYWx3YXlzIGRvIHRoaXMgb24gaXRzIG93biwgd2l0aG91dCByZWx5aW5nIG9uIGFueSBz dGFuZGFyZCBndWlkYW5jZSwgYW5kIHByb3ZpZGUgaXRzIG93biBtZWNoYW5pc20gdG8gYXNzb2Np YXRlIEFQSSByZXNvdXJjZSBpbmRpY2F0b3JzIHdpdGggY2xpZW50IElEcyAtIGJ1dCB0aGlzIHNj ZW5hcmlvIGRvZXMgc3VnZ2VzdCB0aGF0IGl0IHdvdWxkIGJlIGhhbmR5IHRvIGJlIGFibGUgdG8g dXNlIHRoZSBtaWQgdGllciBBUEkgY2xpZW50SUQgYXMgYW4gaWRlbnRpZmllciBpbiB0aGUgcmVx dWVzdCBmcm9tIHRoZSBuYXRpdmUgY2xpZW50IHRvIGdldCB0aGUgYm9vdHN0cmFwIHRva2VuLg0K SSBhZ3JlZSB0aGF0IGRvaW5nIHNvIHRvZGF5IGlzIHN1cGVyIGNvbmZ1c2luZywgYXMgdGhlIGRl dmVsb3BlciB3b3VsZCB1c2Ugc29tZXRoaW5nIHdpdGggImNsaWVudCIgaW4gaXRzIG5hbWUgdG8g aW5kaWNhdGUgYSByZXNvdXJjZS4gVG8gbWUgdGhpcyBpcyBhIGNvbnNlcXVlbmNlIG9mIGV4cHJl c3NpbmcgZXZlcnl0aGluZyBpbiB0ZXJtIG9mIGNsaWVudHMsIHdoaWNoIGNvbWVzIGZyb20gdGhl IE9BdXRoMiBoZXJpdGFnZSBvZiB0aG9zZSBmbG93cywgYnV0IGRvZXNuJ3QgcHJvdmlkZSBhIHdh eSBvZiBtb2RlbGluZyB0aGUgZnJlcXVlbnQgb2NjdXJyZW5jZSBpbiB3aGljaCBhbiBhcHBsaWNh dGlvbiBsZWdpdGltYXRlbHkgcGxheXMgYm90aCB0aGUgcmVzb3VyY2UgKGluIHRoZSBtb3N0IGdl bmVyYWwgc2Vuc2UsIGluY2x1ZGluZyB3ZWIgc2l0ZXMpIGFuZCB0aGUgY2xpZW50IHJvbGUuDQoN Ck9uIFN1biwgTWFyIDMsIDIwMTkgYXQgNjoxNyBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1p dC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KVGhlcmXigJlzIGEgZGlmZmVy ZW5jZSBpbiB0aGUgaW50ZW5kZWQgYXVkaWVuY2Ugb2YgdGhlIGFjY2VzcyB0b2tlbiBpbiBPQXV0 aCB2cy4gdGhlIElEIHRva2VuIGluIE9wZW5JRCBDb25uZWN0LiBJbiBPSURDLCB0aGUgSUQgdG9r ZW4gaXMgcmVhZCBieSB0aGUgY2xpZW50LCBzbyB0aGUgYXVkaWVuY2Ugb2YgdGhlIElEIHRva2Vu IGlzIHRoZSBjbGllbnTigJlzIElELiBUaGF04oCZcyB0aGUgb25seSBwYXJ0eSByZWFkaW5nIHRo YXQgdG9rZW4sIGluIHRoZSB1c3VhbCBjYXNlLiBJbiBPQXV0aCwgdGhlIGFjY2VzcyB0b2tlbiBn b2VzIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UgKG9yIHRoZSDigJxBUEnigJ0gYXMgeW91IHNh eSBoZXJlKS4gVGhpcyByZXNvdXJjZSBjb3VsZCBoYXZlIGFuIGlkZW50aWZpZXIsIGJ1dCBpdOKA mXMgbm90ICpyZWFsbHkqIGEgY2xpZW50IElELCBzaW5jZSB0aGUgcmVzb3VyY2UgaXNu4oCZdCBh IOKAnGNsaWVudOKAnSBpbiB0aGUgT0F1dGggc2Vuc2UuIEFzIEJyaWFuIG1lbnRpb25lZCBpbiBo aXMgZW1haWwsIGR1ZSB0byBzb21lIHVuZm9ydHVuYXRlIG92ZXJsYXAgaW4gZnVuY3Rpb25hbGl0 eSwgdGhlIHJlc291cmNlIHNlcnZlciBjb3VsZCBiZSBpc3N1ZWQgaXRzIG93biBJRCBhbmQgc2Vj cmV0LCBidXQgdGhlc2UgYXJlIHJlYWxseSAqcmVzb3VyY2UqIElEIGFuZCBub3QgKmNsaWVudCog SUQsIGV2ZW4gdGhvdWdoIHRoZXkgdXNlIHRoZSDigJxjbGllbnRfaWTigJ0gcGFyYW1ldGVyIGZv ciBhdXRoZW50aWNhdGlvbi4gVG8gY29uZnVzZSB0aGluZ3MgZXZlbiBmdXJ0aGVyLCBtYW55IGlt cGxlbWVudGF0aW9ucyB3aWxsIHN0b3JlIHJlc291cmNlIHNlcnZlcnMgYXMg4oCcY2xpZW50c+KA nSB3aXRoIGEgc3BlY2lhbCBmbGFnLiBJdOKAmXMgYSBtYXR0ZXIgb2YgaGluZHNpZ2h0IHRoYXQg d2UgY291bGQgaGF2ZSB1c2VkIGFuIGFic3RyYWN0aW9uIGFib3ZlIHRoZXNlIHR3byB0aGluZ3Ms IHNvbWUga2luZCBvZiDigJx0aGluZyB0aGF0IGNhbGxzIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl cuKAnSBvZiB3aGljaCBpbnN0YW5jZXMgd291bGQgaW5jbHVkZSByZXNvdXJjZSBzZXJ2ZXJzIGFu ZCBjbGllbnRzLg0KDQpTbyBpbiB0aGUgZW5kLCB0aGUgYXVkaWVuY2Ugb2YgYW4gYWNjZXNzIHRv a2VuIGlzIG5vdCBhIGNsaWVudCwgYW5kIHRoZXJlZm9yZSB0aGlzIGZpZWxkIGlzbuKAmXQgYSBj bGllbnQgSUQuIEFkZGl0aW9uYWxseSwgdGhlIElEIGdpdmVuIHRvIGEgcmVzb3VyY2Ugc2VydmVy IHdoaWNoIGNvdWxkIGJlIHVzZWQgaW4gZWl0aGVyIHRoZSDigJxyZXNvdXJjZeKAnSBhbmQg4oCc YXVkaWVuY2XigJ0gZmllbGQgaXNu4oCZdCBhIGNsaWVudCBJRCBlaXRoZXIgYmVjYXVzZSB0aGUg cmVzb3VyY2UgaXNu4oCZdCBhIGNsaWVudC4NCg0KQW5kIGZpbmFsbHksIHRoZSDigJxyZXNvdXJj ZeKAnSBpZGVudGlmaWVyIHVzZWQgaW4gdGhpcyBwYXJhbWV0ZXIgaXMgc29tZXRoaW5nIHRoYXQg aGFzIHRvIGJlIGtub3duIHRvIHRoZSBjbGllbnQsIHNvIHRoYXQgdGhlIGNsaWVudCBjYW4gcmVx dWVzdCBpdCBhdCBydW50aW1lLiBBIHN5c3RlbSBpcyB1bmxpa2VseSB0byBwdWJsaXNoIGEgcmVz b3VyY2Ugc2VydmVy4oCZcyBpbnRlcm5hbCBpZGVudGlmaWVyIGluIHRoaXMgd2F5LCBhbmQgd2ls bCBpbnN0ZWFkIHVzZSBhIGRldmVsb3Blci1mYWNpbmcgbmFtZSBvciBhIFVSTCBvZiBzb21lIGZs YXZvci4NCg0KSG9wZSB0aGlzIGNsZWFycyB0aGluZ3MgdXAsIGFzIG11Y2ggYXMgaXQgY2FuIGJl LiBJIGFncmVlIHRoYXQgYmV0d2VlbiDigJxyZXNvdXJjZeKAnSwg4oCcYXVkaWVuY2XigJ0sIGFu ZCDigJxzY29wZeKAnSwgcGx1cyB0aGUgVU1BIHN0YW5kYXJk4oCZcyDigJxwZXJtaXNzaW9u4oCd IHN0cnVjdHVyZSwgdGhpbmdzIGFyZSBtb3JlIHRoYW4gYSBiaXQgbWVzc3kgbm93Lg0KDQrigJQg SnVzdGluDQoNCk9uIEZlYiAyNywgMjAxOSwgYXQgMjo0NiBBTSwgSmFhcCBGcmFuY2tlIDxqYWFw LmZyYW5ja2U9NDBpd2VsY29tZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmphYXAuZnJhbmNr ZT00MGl3ZWxjb21lLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpIaSBhbGwsDQoNCkkg aGF2ZSBzb21lIHF1ZXN0aW9ucy90aG91Z2h0cyBvbiB0aGUgbmV3IGRyYWZ0IGZvciByZXNvdXJj ZSBpbmRpY2F0b3JzLg0KSSBkaWRu4oCZdCBkbyBhbiBpbi1kZXB0aCBzdHVkeSBidXQgd291bGQg bGlrZSB0byBzaGFyZSBteSB0aG91Z2h0cyB3aXRoIHlvdSBhbnl3YXkuDQoNCjEuIEluIHRoaXMg ZHJhZnQsIHRoZSBSZXNvdXJjZSBpcyBpZGVudGlmaWVkIGJ5IOKAmHJlc291cmNl4oCZIHBhcmFt ZXRlci4gRm9yIGV4YW1wbGUsIHdoZW4gdGhlIHJlc291cmNlIGlzIGFuIEFQSSwgSSB3b3VsZCBl eHBlY3QgdGhhdCBBUEkgdG8gdmFsaWRhdGUgdGhlIGFjY2Vzc190b2tlbiBhdCB0aGUgcmVzb3Vy Y2Ugc2VydmVyLiBUaGUgcHJvdG9jb2wgZm9yIHRoaXMgd291bGQgYmUgYmFzZWQgb24gdGhlIEFQ SeKAmXMgY2xpZW50X2lkLCBzbyBmcm9tIHRoYXQgYW5nbGUgdXNpbmcgdGhlIHRoZSBjbGllbnRf aWQgY291bGQgYmUgYSBkaWZmZXJlbnQgd2F5IHRvIGluZGljYXRlIHRoZSBpbnRlbmRlZCByZWNp cGllbnQgb2YgdGhlIGFjY2VzcyB0b2tlbi4NCg0KMi4gSSBhbHNvIHRoaW5rIHRoYXQgdGhlIOKA mHJlc291cmNl4oCZIHBhcmFtZXRlciB3b3VsZCBiZSBjbG9zZWx5IHJlbGF0ZWQgdG8gdGhlIOKA nGF1ZOKAnSBjbGFpbSBzcGVjaWZpZWQgYnkgdGhlIE9wZW5JRCBDb25uZWN0IHNwZWNpZmljYXRp b25zLiBJIHRoaW5rIGl0IGlzIGdldHRpbmcgbW9yZSBhbmQgbW9yZSBjb21tb24gdG8gdXNlIHRo ZSBPSURDLXByb3RvY29sIOKAnG9uIHRvcCBvZiBPQXV0aOKAnSwgc28gSeKAmW0gd29uZGVyaW5n IGhvdyB0aGUgcmVzb3VyY2UgcGFyYW1ldGVyIHdvdWxkIHJlbGF0ZSB0byB0aGF0LiBUaGUgdmFs dWVzIG9mIHRoZSDigJhhdWTigJkgcGFyYW1ldGVyIGFyZSBhbHNvIGNsaWVudF9pZOKAmXMuDQoN ClRoYW5rcyBpbiBhZHZhbmNlIGZvciByZXNwb25kaW5nIHRvIG15IHZpZXdzLg0KQ2lhbyENCg0K SmFhcCBGcmFuY2tlDQoNCg0KDQpPbiAyNiBGZWIgMjAxOSwgYXQgMjE6MDAsIG9hdXRoLXJlcXVl c3RAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLXJlcXVlc3RAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICBk cmFmdC1pZXRmLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDINCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCg== --_000_F3A5CCAD78214723A37FFC64333479B0mitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkJ1dCBpbiB0aGlzIHNjZW5hcmlvLCB0aGUg4oCc YXVkaWVuY2XigJ0gb2YgdGhlIHRva2VuIGlzIHRoZSByZXNvdXJjZSBzZXJ2ZXLigJlzIElELCBy aWdodD8gQW5kIG5vdCB0aGUgb3JpZ2luYWwgY2xpZW504oCZcyBjbGllbnQgaWQuIFRoaXMgaXMg YSBjYXNlIHdoZXJlIHRoZSBSUyBpcyA6YWxzbzogYSBjbGllbnQsIGJlY2F1c2Ugb2YgdGhlIHRv a2VuIGV4Y2hhbmdlIGJpdCwgYnV0IHlvdSBjYW7igJl0IHNheSB0aGUgYXVkaWVuY2UgaXMgYWx3 YXlzIGdvaW5nDQogdG8gYmUgYSBjbGllbnQgSUQgYmVjYXVzZSBtb3N0IHJlc291cmNlIHNlcnZl cnMgb3V0IHRoZXJlIGFyZW7igJl0IGFsc28gZ29pbmcgdG8gYmUgY2xpZW50cyBpbiB0aGVpciBv d24gcmlnaHQuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyI+DQrigJQgSnVzdGluPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1hciA0 LCAyMDE5LCBhdCAxOjE1IFBNLCBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRv OlZpdHRvcmlvQGF1dGgwLmNvbSIgY2xhc3M9IiI+Vml0dG9yaW9AYXV0aDAuY29tPC9hPiZndDsg d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPlRvIGFkZCBzb21lIGNvbG9yLCBo ZXJlIHRoZXJlJ3MgYSBjb25jcmV0ZSBzY2VuYXJpbyB3aGVyZSBtYW55IG9mIHRob3NlIGNvbmNl cHRzIGNvbWUgdG9nZXRoZXIgKG9yIGNvbGxpZGUsIGlmIHlvdSBwcmVmZXIpLg0KPGRpdiBjbGFz cz0iIj5BenVyZSBBRCBpbXBsZW1lbnRzIGFtIGVhcmx5IGRyYWZ0IG9mIHRva2VuIGV4Y2hhbmdl LCBsYXJnZWx5IGZvciBpbXBsZW1lbnRpbmcgYSBjbG91ZCBmcmllbmRseSB2ZXJzaW9uIG9mIGtl cmJlcm9zIGNvbnN0cmFpbmVkIGRlbGVnYXRpb24tIHNheSBhIG5hdGl2ZSBjbGllbnQgY2FsbHMg YSBtaWQgdGllciBBUEksIGFuZCB0aGUgbWlkIHRpZXIgQVBJIHR1cm5zIGFyb3VuZCBhbmQgY2Fs bHMgYSBiYWNrZW5kIEFQSSBmbG93aW5nDQogdGhlIGlkZW50aXR5IG9mIHRoZSB1c2VyLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5JbiBvcmRlciB0byBkbyBzbywgdGhlIG1pZC10aWVyIEFQSSBwZXJm b3JtcyBhIHJlcXVlc3QgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFza2luZyBmb3IgdGhl IHNjb3BlcyB0aGUgYmFja2VuZCBBUEkgcmVxdWlyZXMsIGFuZCBwcmVzZW50aW5nIGFzIGEgZ3Jh bnQgdGhlIGFjY2VzcyB0b2tlbiBpdCByZWNlaXZlZCBmcm9tIHRoZSBuYXRpdmUgY2xpZW50LiBU aGUgQVMgdmVyaWZpZXMgdGhhdCB0aGUgcmVzb3VyY2UNCiBvd25lciBwcmV2aW91c2x5IGdyYW50 ZWQgY29uc2VudCAoYXMgdGhlcmUgaXMgbm8gb3Bwb3J0dW5pdHkgdG8gc2hvdyBhbnkgVVgpLiBI ZXJlJ3MgdGhlIHJlbGV2YW50IHBhcnQ6DQo8YiBjbGFzcz0iIj50aGUgQVMgYWxzbyB2ZXJpZmll cyB3aGV0aGVyIHRoZSBhdWRpZW5jZSBpbiB0aGUgYWNjZXNzIHRva2VuIChpbiB3aGF0ZXZlciB3 YXkgaXQgaXMgZXhwcmVzc2VkKSBjb3JyZXNwb25kcyB0byB0aGUgY2xpZW50IElEIG9mIHRoZSBy ZXF1ZXN0b3IsIHRvIHByZXZlbnQgTUlUTSBhdHRhY2tzIHRvIGdhaW4gYW4gYXZlbnVlIGZvciBt aW50aW5nIG5ldyB0b2tlbnMgZnJvbSBhcmJpdHJhcmlseSBjYXB0dXJlZCBBVHM8L2I+LiBJbg0K IG90aGVyIHdvcmRzLCB0aGUgQVMgbmVlZHMgYSBtZWNoYW5pc20gdG8ga25vdyB0aGF0IHRoZSBy ZXNvdXJjZSBpbmRpY2F0b3IgZm9yIHRoZSBtaWQgdGllciBBUEkgYW5kIHRoZSBjbGllbnQgSUQg dXNlZCBieSB0aGUgYXBwIGltcGxlbWVudGluZyB0aGF0IEFQSSB0byBhc2sgZm9yIG5ldyB0b2tl bnMgYXJlIGluIGZhY3QgcG9pbnRpbmcgdG8gdGhlIHNhbWUgZW50aXR5LjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGUgQVMgY2FuIGFsd2F5cyBkbyB0aGlzIG9uIGl0cyBvd24sIHdpdGhvdXQgcmVs eWluZyBvbiBhbnkgc3RhbmRhcmQgZ3VpZGFuY2UsIGFuZCBwcm92aWRlIGl0cyBvd24gbWVjaGFu aXNtIHRvIGFzc29jaWF0ZSBBUEkgcmVzb3VyY2UgaW5kaWNhdG9ycyB3aXRoIGNsaWVudCBJRHMg LSBidXQgdGhpcyBzY2VuYXJpbyBkb2VzIHN1Z2dlc3QgdGhhdCBpdCB3b3VsZCBiZSBoYW5keSB0 byBiZSBhYmxlIHRvIHVzZSB0aGUgbWlkDQogdGllciBBUEkgY2xpZW50SUQgYXMgYW4gaWRlbnRp ZmllciBpbiB0aGUgcmVxdWVzdCBmcm9tIHRoZSBuYXRpdmUgY2xpZW50IHRvIGdldCB0aGUgYm9v dHN0cmFwIHRva2VuLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFncmVlIHRoYXQgZG9pbmcgc28g dG9kYXkgaXMgc3VwZXIgY29uZnVzaW5nLCBhcyB0aGUgZGV2ZWxvcGVyIHdvdWxkIHVzZSBzb21l dGhpbmcgd2l0aCAmcXVvdDtjbGllbnQmcXVvdDsgaW4gaXRzIG5hbWUgdG8gaW5kaWNhdGUgYSBy ZXNvdXJjZS4gVG8gbWUgdGhpcyBpcyBhIGNvbnNlcXVlbmNlIG9mIGV4cHJlc3NpbmcgZXZlcnl0 aGluZyBpbiB0ZXJtIG9mIGNsaWVudHMsIHdoaWNoIGNvbWVzIGZyb20gdGhlIE9BdXRoMiBoZXJp dGFnZQ0KIG9mIHRob3NlIGZsb3dzLCBidXQgZG9lc24ndCBwcm92aWRlIGEgd2F5IG9mIG1vZGVs aW5nIHRoZSBmcmVxdWVudCBvY2N1cnJlbmNlIGluIHdoaWNoIGFuIGFwcGxpY2F0aW9uIGxlZ2l0 aW1hdGVseSBwbGF5cyBib3RoIHRoZSByZXNvdXJjZSAoaW4gdGhlIG1vc3QgZ2VuZXJhbCBzZW5z ZSwgaW5jbHVkaW5nIHdlYiBzaXRlcykgYW5kIHRoZSBjbGllbnQgcm9sZS4mbmJzcDs8L2Rpdj4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBk aXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFN1biwgTWFyIDMsIDIwMTkgYXQgNjoxNyBQ TSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiBjbGFz cz0iIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBw eCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxl ZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7IiBjbGFzcz0i Ij5UaGVyZeKAmXMgYSBkaWZmZXJlbmNlIGluIHRoZSBpbnRlbmRlZCBhdWRpZW5jZSBvZiB0aGUg YWNjZXNzIHRva2VuIGluIE9BdXRoIHZzLiB0aGUgSUQgdG9rZW4gaW4gT3BlbklEIENvbm5lY3Qu IEluIE9JREMsIHRoZSBJRCB0b2tlbiBpcyByZWFkIGJ5IHRoZSBjbGllbnQsIHNvIHRoZSBhdWRp ZW5jZSBvZiB0aGUgSUQgdG9rZW4gaXMgdGhlIGNsaWVudOKAmXMgSUQuDQogVGhhdOKAmXMgdGhl IG9ubHkgcGFydHkgcmVhZGluZyB0aGF0IHRva2VuLCBpbiB0aGUgdXN1YWwgY2FzZS4gSW4gT0F1 dGgsIHRoZSBhY2Nlc3MgdG9rZW4gZ29lcyB0byB0aGUgcHJvdGVjdGVkIHJlc291cmNlIChvciB0 aGUg4oCcQVBJ4oCdIGFzIHlvdSBzYXkgaGVyZSkuIFRoaXMgcmVzb3VyY2UgY291bGQgaGF2ZSBh biBpZGVudGlmaWVyLCBidXQgaXTigJlzIG5vdCAqcmVhbGx5KiBhIGNsaWVudCBJRCwgc2luY2Ug dGhlIHJlc291cmNlIGlzbuKAmXQgYSDigJxjbGllbnTigJ0NCiBpbiB0aGUgT0F1dGggc2Vuc2Uu IEFzIEJyaWFuIG1lbnRpb25lZCBpbiBoaXMgZW1haWwsIGR1ZSB0byBzb21lIHVuZm9ydHVuYXRl IG92ZXJsYXAgaW4gZnVuY3Rpb25hbGl0eSwgdGhlIHJlc291cmNlIHNlcnZlciBjb3VsZCBiZSBp c3N1ZWQgaXRzIG93biBJRCBhbmQgc2VjcmV0LCBidXQgdGhlc2UgYXJlIHJlYWxseSAqcmVzb3Vy Y2UqIElEIGFuZCBub3QgKmNsaWVudCogSUQsIGV2ZW4gdGhvdWdoIHRoZXkgdXNlIHRoZSDigJxj bGllbnRfaWTigJ0gcGFyYW1ldGVyDQogZm9yIGF1dGhlbnRpY2F0aW9uLiBUbyBjb25mdXNlIHRo aW5ncyBldmVuIGZ1cnRoZXIsIG1hbnkgaW1wbGVtZW50YXRpb25zIHdpbGwgc3RvcmUgcmVzb3Vy Y2Ugc2VydmVycyBhcyDigJxjbGllbnRz4oCdIHdpdGggYSBzcGVjaWFsIGZsYWcuIEl04oCZcyBh IG1hdHRlciBvZiBoaW5kc2lnaHQgdGhhdCB3ZSBjb3VsZCBoYXZlIHVzZWQgYW4gYWJzdHJhY3Rp b24gYWJvdmUgdGhlc2UgdHdvIHRoaW5ncywgc29tZSBraW5kIG9mIOKAnHRoaW5nIHRoYXQgY2Fs bHMNCiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0gb2Ygd2hpY2ggaW5zdGFuY2VzIHdvdWxk IGluY2x1ZGUgcmVzb3VyY2Ugc2VydmVycyBhbmQgY2xpZW50cy4mbmJzcDsNCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNvIGluIHRoZSBlbmQsIHRo ZSBhdWRpZW5jZSBvZiBhbiBhY2Nlc3MgdG9rZW4gaXMgbm90IGEgY2xpZW50LCBhbmQgdGhlcmVm b3JlIHRoaXMgZmllbGQgaXNu4oCZdCBhIGNsaWVudCBJRC4gQWRkaXRpb25hbGx5LCB0aGUgSUQg Z2l2ZW4gdG8gYSByZXNvdXJjZSBzZXJ2ZXIgd2hpY2ggY291bGQgYmUgdXNlZCBpbiBlaXRoZXIg dGhlIOKAnHJlc291cmNl4oCdIGFuZCDigJxhdWRpZW5jZeKAnSBmaWVsZCBpc27igJl0IGEgY2xp ZW50IElEIGVpdGhlcg0KIGJlY2F1c2UgdGhlIHJlc291cmNlIGlzbuKAmXQgYSBjbGllbnQuJm5i c3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5BbmQgZmluYWxseSwgdGhlIOKAnHJlc291cmNl4oCdIGlkZW50aWZpZXIgdXNlZCBpbiB0 aGlzIHBhcmFtZXRlciBpcyBzb21ldGhpbmcgdGhhdCBoYXMgdG8gYmUga25vd24gdG8gdGhlIGNs aWVudCwgc28gdGhhdCB0aGUgY2xpZW50IGNhbiByZXF1ZXN0IGl0IGF0IHJ1bnRpbWUuIEEgc3lz dGVtIGlzIHVubGlrZWx5IHRvIHB1Ymxpc2ggYSByZXNvdXJjZSBzZXJ2ZXLigJlzIGludGVybmFs IGlkZW50aWZpZXIgaW4gdGhpcyB3YXksIGFuZA0KIHdpbGwgaW5zdGVhZCB1c2UgYSBkZXZlbG9w ZXItZmFjaW5nIG5hbWUgb3IgYSBVUkwgb2Ygc29tZSBmbGF2b3IuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ib3BlIHRoaXMgY2xlYXJz IHRoaW5ncyB1cCwgYXMgbXVjaCBhcyBpdCBjYW4gYmUuIEkgYWdyZWUgdGhhdCBiZXR3ZWVuIOKA nHJlc291cmNl4oCdLCDigJxhdWRpZW5jZeKAnSwgYW5kIOKAnHNjb3Bl4oCdLCBwbHVzIHRoZSBV TUEgc3RhbmRhcmTigJlzIOKAnHBlcm1pc3Npb27igJ0gc3RydWN0dXJlLCB0aGluZ3MgYXJlIG1v cmUgdGhhbiBhIGJpdCBtZXNzeSBub3cuPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsiIGNsYXNzPSIiPg0K4oCUIEp1c3RpbjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5PbiBGZWIgMjcsIDIwMTksIGF0IDI6NDYgQU0sIEphYXAgRnJhbmNrZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmphYXAuZnJhbmNrZT00MGl3ZWxjb21lLmNvbUBkbWFyYy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmphYXAuZnJhbmNrZT00MGl3ZWxjb21lLmNvbUBk bWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJnbWFpbC1tXzE2 NDgwNDg4MDY0ODcxMzM3MzFBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFwOiBicmVhay13b3JkOyIgY2xhc3M9IiI+SGkg YWxsLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ SSBoYXZlIHNvbWUgcXVlc3Rpb25zL3Rob3VnaHRzIG9uIHRoZSBuZXcgZHJhZnQgZm9yIHJlc291 cmNlIGluZGljYXRvcnMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgZGlkbuKAmXQgZG8gYW4gaW4t ZGVwdGggc3R1ZHkgYnV0IHdvdWxkIGxpa2UgdG8gc2hhcmUgbXkgdGhvdWdodHMgd2l0aCB5b3Ug YW55d2F5LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+MS4gSW4gdGhpcyBkcmFmdCwgdGhlIFJlc291cmNlIGlzIGlkZW50aWZpZWQgYnkg 4oCYcmVzb3VyY2XigJkgcGFyYW1ldGVyLiBGb3IgZXhhbXBsZSwgd2hlbiB0aGUgcmVzb3VyY2Ug aXMgYW4gQVBJLCBJIHdvdWxkIGV4cGVjdCB0aGF0IEFQSSB0byB2YWxpZGF0ZSB0aGUgYWNjZXNz X3Rva2VuIGF0IHRoZSByZXNvdXJjZSBzZXJ2ZXIuIFRoZSBwcm90b2NvbCBmb3IgdGhpcyB3b3Vs ZCBiZSBiYXNlZCBvbiB0aGUgQVBJ4oCZcyBjbGllbnRfaWQsDQogc28gZnJvbSB0aGF0IGFuZ2xl IHVzaW5nIHRoZSB0aGUgY2xpZW50X2lkIGNvdWxkIGJlIGEgZGlmZmVyZW50IHdheSB0byBpbmRp Y2F0ZSB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoZSBhY2Nlc3MgdG9rZW4uPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4yLiBJIGFs c28gdGhpbmsgdGhhdCB0aGUg4oCYcmVzb3VyY2XigJkgcGFyYW1ldGVyIHdvdWxkIGJlIGNsb3Nl bHkgcmVsYXRlZCB0byB0aGUg4oCcYXVk4oCdIGNsYWltIHNwZWNpZmllZCBieSB0aGUgT3BlbklE IENvbm5lY3Qgc3BlY2lmaWNhdGlvbnMuIEkgdGhpbmsgaXQgaXMgZ2V0dGluZyBtb3JlIGFuZCBt b3JlIGNvbW1vbiB0byB1c2UgdGhlIE9JREMtcHJvdG9jb2wg4oCcb24gdG9wIG9mIE9BdXRo4oCd LCBzbyBJ4oCZbSB3b25kZXJpbmcgaG93DQogdGhlIHJlc291cmNlIHBhcmFtZXRlciB3b3VsZCBy ZWxhdGUgdG8gdGhhdC4gVGhlIHZhbHVlcyBvZiB0aGUg4oCYYXVk4oCZIHBhcmFtZXRlciBhcmUg YWxzbyBjbGllbnRfaWTigJlzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzIGluIGFkdmFuY2UgZm9yIHJlc3BvbmRpbmcgdG8g bXkgdmlld3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNpYW8hPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5KYWFwIEZyYW5ja2U8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDI2IEZlYiAyMDE5LCBhdCAyMTowMCwg PGEgaHJlZj0ibWFpbHRvOm9hdXRoLXJlcXVlc3RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj4NCm9hdXRoLXJlcXVlc3RAaWV0Zi5vcmc8L2E+IHdyb3RlOjwvZGl2Pg0KPGJyIGNs YXNzPSJnbWFpbC1tXzE2NDgwNDg4MDY0ODcxMzM3MzFBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250 LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9u dC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3Rl eHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3Jk LXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lO2Zsb2F0Om5vbmU7ZGlzcGxheTppbmxp bmUiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwO2RyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2Ut aW5kaWNhdG9ycy0wMjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIi Pg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9 IiI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_F3A5CCAD78214723A37FFC64333479B0mitedu_-- From nobody Fri Mar 8 00:35:50 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C68BA1311A2; Fri, 8 Mar 2019 00:35:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <155203414877.3260.2983036816042685795@ietfa.amsl.com> Date: Fri, 08 Mar 2019 00:35:48 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 08:35:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Security Best Current Practice Authors : Torsten Lodderstedt John Bradley Andrey Labunets Daniel Fett Filename : draft-ietf-oauth-security-topics-12.txt Pages : 40 Date : 2019-03-08 Abstract: This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 8 04:28:35 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF7D127980 for ; Fri, 8 Mar 2019 04:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1V4wba5UiS_t for ; Fri, 8 Mar 2019 04:28:31 -0800 (PST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609481276D0 for ; Fri, 8 Mar 2019 04:28:31 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id j89so16242269edb.9 for ; Fri, 08 Mar 2019 04:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=4IDKJlVbxKwK2lcIxob0+lr5HTT8/K0fCBc4olVHTOg=; b=G2Yd8WPuEgDO6COISCeh6xqYDyqt46As/8RBnv/FciPfquJnZIcacKxfwfC+MpcK+c NdEKcHUviMbmNBrjprDBfo686+ABY65LLYe6zXVe1AcaKaFLjhnSCHEKZ2YlO8o0UJtc Rzp4gwzj5Nsk5Mfcf36GQDs6TP1du2tLkg9+Qns/vmt6DvoloU82DwvlJOTTvmcqNXy2 VzITpoxqRW9NCKfQTFIIcI5CMTJWHHyD9c6XQA9hy0GCXbZxGPcl+x29sryJDNxDOeea 2xaRjAM94kETXTipPy5WvMS/Lq7oAsoOIvqUFAFCWnyTphTwWkEeT/yqEvHfdYhhg8h1 KcMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=4IDKJlVbxKwK2lcIxob0+lr5HTT8/K0fCBc4olVHTOg=; b=dLtSlPk22Z7eEtfw538WZ6FPX6i5uUI2X5edVw8FOotLrcwaBfDgohfIqjNZXvDtUC K9oTNPkCmoT7z4R/AripHP2+CR8/ne62KJvZrE37AFTUuAuMhWSQf/an2IWz5qi4avSO UfJBRLTh8Sz+l57i0k8ai+Tr3h/420hlj5uXasEjcNNQyv94E4ux1gDrUhPfLMLjpsK0 EIOYvDwHLnPA35svkYgUwXp3Tq3XUfnrArPvbJ2Ntwp08xhUYrPv7Z//uIhYzFp8AXJ3 r5gaQ33/Kk02X/2E4ky7DlS9riqWt+p/HAyNH2NXBBD0YKqAq4rlo2ekRs49jWVQ8Vlp BAbQ== X-Gm-Message-State: APjAAAVD6NYG11iLPODxQVI0Tzj7DPqAL630i+jM00A5tpvZ9WEjzSYC D+G6kkX2uHRE88kEaCYYlpogqZkFeGU= X-Google-Smtp-Source: APXvYqwzNzNk2bumWEnCHaVZ6azi65a1+BppVMvkqQXRRb/Z38pX4g9m7u6QO0PEBWk3M0iwmGyc5Q== X-Received: by 2002:a17:906:90c5:: with SMTP id v5mr11846716ejw.173.1552048109302; Fri, 08 Mar 2019 04:28:29 -0800 (PST) Received: from papegaaij.localnet ([195.35.227.200]) by smtp.gmail.com with ESMTPSA id k26sm1387793ejv.63.2019.03.08.04.28.28 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Mar 2019 04:28:28 -0800 (PST) From: Emond Papegaaij To: OAuth@ietf.org Date: Fri, 08 Mar 2019 13:22:36 +0100 Message-ID: <6312173.9VWeF3DjuQ@papegaaij> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Device flow error response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 12:28:34 -0000 Dear all, I'm working on an implementation of the OAuth 2.0 Device Flow for Browserless and Input Constrained Devices and noticed a possible omission in the spec. Section 3.2 describes the Device Authorization Response, but only the success response is specified, not the error response. I would have expected a standard OAuth 2.0 error response, probably with the following error codes: invalid_request, invalid_client and invalid_scope. Best regards, Emond Papegaaij Topicus KeyHub From nobody Fri Mar 8 13:24:48 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6254F126DFA for ; Fri, 8 Mar 2019 13:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 bRewV_xg5OCq for ; Fri, 8 Mar 2019 13:24:45 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0FC124408 for ; Fri, 8 Mar 2019 13:24:45 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id v2so23017614ith.3 for ; Fri, 08 Mar 2019 13:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dx1oxpSVFQM90e3OyPm+K79Y4Ha4qwKY1URgefPjjtg=; b=OumBHiPuk3hwKwQCfHKkD6Re9KdkWqoYGmrTvbKh/TlZTXRAKgw7ZGj9Kyt/D7ARQH oysV7TuF6L2kxFL4i/RXfHb+fSTZvoQ+c7cWXTIjEMVR7u7Yql7vspjcYjGUYy8ljhFz i8ILUyzbqD3KBeXUwWbeaN9SYk6dxJ0Hew1fA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dx1oxpSVFQM90e3OyPm+K79Y4Ha4qwKY1URgefPjjtg=; b=qb7zDBoBaSF+Tac1u4fhvr1phWkfrmAq77sbvp+Gq82TSnkQMIjRDH+uiXg6rQqVM5 LmyApquKxS4GNYtqlwbOJ8Sv8CclIXX2POuQFJcc9xm5W7C1yEkgqfFgZ8guEdiL2Swf iUvzAQK3A7ElVqVkgToRqAcRrHdkVNJUeBiyhS+6fUFfBcwqSz5LKXokZjOFxtQzvExn Bge1O3Lka/NLaL9JontuEagvn2XNuXwZLDNJxUCFBCna+S2s8ni/Q0ByyrhDoYawDFHM XyXn1ySmrrfCnNyvFPeTwb1/grkcgElnFIQvIu1AVmAN/BLZsaPsY7B3ozFgofuFL9DS BWbA== X-Gm-Message-State: APjAAAX4oZYVx4rjKSbkFMRmGG3B3hqq9GQnPn0mu1/BDbMu7Ws3SOQ4 twte0WO3YFh2XzMHqFLk16cBTB9iLwIyofQQD0XcmhOS0w78a0mSpGYiCLasemWhtq+cHmT8Ilk JESeaRc50UsC+Mw== X-Google-Smtp-Source: APXvYqwD5Q0xLcZno5fBkLxJD64EUnj3J7qJ8EKtCEFT+6REpyFcZl+Ho5oM5dJMd0kA3monJnPy0KJet3MY8U04Hcs= X-Received: by 2002:a24:2487:: with SMTP id f129mr9488544ita.124.1552080284299; Fri, 08 Mar 2019 13:24:44 -0800 (PST) MIME-Version: 1.0 References: <6312173.9VWeF3DjuQ@papegaaij> In-Reply-To: <6312173.9VWeF3DjuQ@papegaaij> From: Brian Campbell Date: Fri, 8 Mar 2019 14:24:17 -0700 Message-ID: To: Emond Papegaaij Cc: oauth Content-Type: multipart/alternative; boundary="00000000000002520b05839bda25" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device flow error response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 21:24:48 -0000 --00000000000002520b05839bda25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While probably not terribly important from an interoperability perspective, I agree that does seem like an omission. I took a quick look at our implementation and bad requests to the device authorization endpoint will indeed return what is a standard OAuth 2.0 error response normally from the token endpoint with invalid_client or invalid_scope error codes. And a little bit of poking at Google's device authorization endpoint suggests it behaves similarly. I suspect it's pretty typical. On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij wrote: > Dear all, > > I'm working on an implementation of the OAuth 2.0 Device Flow for > Browserless > and Input Constrained Devices and noticed a possible omission in the spec= . > Section 3.2 describes the Device Authorization Response, but only the > success > response is specified, not the error response. I would have expected a > standard OAuth 2.0 error response, probably with the following error > codes: > invalid_request, invalid_client and invalid_scope. > > Best regards, > Emond Papegaaij > Topicus KeyHub > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000002520b05839bda25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While probably not terribly importan= t from an interoperability perspective, I agree that does seem like an omis= sion.

I took a quick look at our implementati= on and bad requests to the device authorization endpoint will indeed return= what is a standard OAuth 2.0 error response normally from the token endpoi= nt with invalid_client or invalid_scope error codes. And a little bit of po= king at Google's device authorization endpoint suggests it behaves simi= larly. I suspect it's pretty typical.


On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij <emond.papegaaij@gmail.com> wrote:<= br>
Dear all,

I'm working on an implementation of the OAuth 2.0 Device Flow for Brows= erless
and Input Constrained Devices and noticed a possible omission in the spec. =
Section 3.2 describes the Device Authorization Response, but only the succe= ss
response is specified, not the error response. I would have expected a
standard OAuth 2.0 error response, probably with the following error codes:=
invalid_request, invalid_client and invalid_scope.

Best regards,
Emond Papegaaij
Topicus KeyHub


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000002520b05839bda25-- From nobody Fri Mar 8 15:33:25 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39301277E7 for ; Fri, 8 Mar 2019 15:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NTtGsA9T9-tn for ; Fri, 8 Mar 2019 15:33:22 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DE8126DFA for ; Fri, 8 Mar 2019 15:33:22 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0F88EB82D32; Fri, 8 Mar 2019 15:33:21 -0800 (PST) To: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp, kaduk@mit.edu, ekr@rtfm.com, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: adelcambre@gmail.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190308233321.0F88EB82D32@rfc-editor.org> Date: Fri, 8 Mar 2019 15:33:21 -0800 (PST) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC7519 (5648) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 23:33:24 -0000 The following errata report has been submitted for RFC7519, "JSON Web Token (JWT)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5648 -------------------------------------- Type: Editorial Reported by: Andy Delcambre Section: 1 Original Text ------------- JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159] object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization. The suggested pronunciation of JWT is the same as the English word "jot". Corrected Text -------------- JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159] object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization. Notes ----- The suggested pronunciation is strange and confusing. It makes it hard to onboard new people verbally and always requires an explanation of the pronunciation. The standard already has a perfectly reasonable initialism of JWT that clearly refers to JSON Web Tokens. It is jarring to suggest a pronunciation that does not map to the letters of the spec, and in my experience often leads to confusion when used. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7519 (draft-ietf-oauth-json-web-token-32) -------------------------------------- Title : JSON Web Token (JWT) Publication Date : May 2015 Author(s) : M. Jones, J. Bradley, N. Sakimura Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Mar 8 16:08:14 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95900127918 for ; Fri, 8 Mar 2019 16:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=salesforce.com 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 eSQiFAyCHYNX for ; Fri, 8 Mar 2019 16:08:09 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63F0412788F for ; Fri, 8 Mar 2019 16:08:09 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id a3so15269211pff.11 for ; Fri, 08 Mar 2019 16:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g1ki4P6zXDRgHHos0duw5eosA1DJVCq5QvNX96wcchc=; b=BVhjxSc9dDpMT8cL4W8np4T1/+v+kg2DbOaNsfNRoyCH3FFNGcbknOTqfbcEJVrF+m /MnZ50UWf0AfFQShEuJwfGvdzquWzyhhnRiVP92tn6leYmiMd2PebLcB6lWQwIIP+mKA 6x7Fk4Vvd23Ppxq4hVqQ2JSrQBg8pMYen/N+8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g1ki4P6zXDRgHHos0duw5eosA1DJVCq5QvNX96wcchc=; b=Tx9UDcZenwLJV0C5aDL+Fa7WNlN52tqMWClbXnZajub77asFuvnGvZN9bhLtINVFpV AxN10Fq7kaLnk2TrMDo+4ImFJ8OqWWyFpo+1fN6UVwReX07K6ci3MU/Ax2ply/sjHyte MyWV5MJp2tL7kIVG9ZmqQjOv/OTgB0BDijNF+VvxinT29Xq3QXPqAVoR6Du+6LK3bk1f ZMphFk0hRuiU/X7jmiGeSDj/l0KQGDYGgmcaGXyj4r1NfU8g6yhCgq/iDHqKMWh+4KgK 1efpNlbqLhzi3zoLqodc4dell/e1MCFp23t5l7plBw3ofebiJb5GwTY9Y58BZ4vJi0vM whWQ== X-Gm-Message-State: APjAAAVoCbExhajLFqI11ZlzpvUufd+K1DV2P5UjALkc/WshxhDMNHAn VvMkeqBOFyjT6rcQGKc8N8wWPQ== X-Google-Smtp-Source: APXvYqxmYNjZFX2Ps2zMOsCVzR93h9TGr09IUh7BRYyPSgVxXvXk7Bjq2Y9FdCCCf1zh8gggq1b/BA== X-Received: by 2002:a65:63c8:: with SMTP id n8mr18999495pgv.158.1552090088762; Fri, 08 Mar 2019 16:08:08 -0800 (PST) Received: from [10.235.166.174] (mobile-166-137-179-166.mycingular.net. [166.137.179.166]) by smtp.gmail.com with ESMTPSA id 20sm18494391pfs.182.2019.03.08.16.08.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 16:08:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Chuck Mortimore X-Mailer: iPhone Mail (16D57) In-Reply-To: <20190308233321.0F88EB82D32@rfc-editor.org> Date: Fri, 8 Mar 2019 16:08:06 -0800 Cc: mbj@microsoft.com, ve7jtb@ve7jtb.com, n-sakimura@nri.co.jp, kaduk@mit.edu, ekr@rtfm.com, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com, adelcambre@gmail.com, oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190308233321.0F88EB82D32@rfc-editor.org> To: RFC Errata System Archived-At: Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC7519 (5648) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 00:08:13 -0000 Its a good suggestion. Curious if you=E2=80=99ll get any reaction. =20 > On Mar 8, 2019, at 3:33 PM, RFC Errata System w= rote: >=20 > The following errata report has been submitted for RFC7519, > "JSON Web Token (JWT)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5648 >=20 > -------------------------------------- > Type: Editorial > Reported by: Andy Delcambre >=20 > Section: 1 >=20 > Original Text > ------------- > JSON Web Token (JWT) is a compact claims representation format > intended for space constrained environments such as HTTP > Authorization headers and URI query parameters. JWTs encode claims > to be transmitted as a JSON [RFC7159] object that is used as the > payload of a JSON Web Signature (JWS) [JWS] structure or as the > plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling > the claims to be digitally signed or integrity protected with a > Message Authentication Code (MAC) and/or encrypted. JWTs are always > represented using the JWS Compact Serialization or the JWE Compact > Serialization. >=20 > The suggested pronunciation of JWT is the same as the English word > "jot". >=20 >=20 >=20 > Corrected Text > -------------- > JSON Web Token (JWT) is a compact claims representation format > intended for space constrained environments such as HTTP > Authorization headers and URI query parameters. JWTs encode claims > to be transmitted as a JSON [RFC7159] object that is used as the > payload of a JSON Web Signature (JWS) [JWS] structure or as the > plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling > the claims to be digitally signed or integrity protected with a > Message Authentication Code (MAC) and/or encrypted. JWTs are always > represented using the JWS Compact Serialization or the JWE Compact > Serialization. >=20 >=20 > Notes > ----- > The suggested pronunciation is strange and confusing. It makes it hard to o= nboard new people verbally and always requires an explanation of the pronunc= iation. The standard already has a perfectly reasonable initialism of JWT th= at clearly refers to JSON Web Tokens. It is jarring to suggest a pronunciati= on that does not map to the letters of the spec, and in my experience often l= eads to confusion when used. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7519 (draft-ietf-oauth-json-web-token-32) > -------------------------------------- > Title : JSON Web Token (JWT) > Publication Date : May 2015 > Author(s) : M. Jones, J. Bradley, N. Sakimura > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Mar 11 05:51:09 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66033124BF6; Mon, 11 Mar 2019 05:51:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <155230866136.16845.8206288715859068410@ietfa.amsl.com> Date: Mon, 11 Mar 2019 05:51:01 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 12:51:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution Authors : John Bradley Phil Hunt Michael B. Jones Hannes Tschofenig Mihaly Meszaros Filename : draft-ietf-oauth-pop-key-distribution-05.txt Pages : 15 Date : 2019-03-11 Abstract: RFC 6750 specified the bearer token concept for securing access to protected resources. Bearer tokens need to be protected in transit as well as at rest. When a client requests access to a protected resource it hands-over the bearer token to the resource server. The OAuth 2.0 Proof-of-Possession security concept extends bearer token security and requires the client to demonstrate possession of a key when accessing a protected resource. This document describes how the client requests and obtains a PoP access token from the authorization server for use with HTTPS-based transport. Alternative transports, for example using the Constrained Application Protocol (CoAP), have been specified in companion specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-05 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 05:52:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5756130E6E for ; Mon, 11 Mar 2019 05:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 6mVULmjUIT81 for ; Mon, 11 Mar 2019 05:52:06 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10048.outbound.protection.outlook.com [40.107.1.48]) (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 44CD313104A for ; Mon, 11 Mar 2019 05:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yz20ciyEfdy60DB7/PWGhCV22oVtFkOUD4EpPHTsOK4=; b=FEEc5YPYkGge9Us5LEjdXSbjFcGhfk4I/NXrTRurii8r83gQYNT4u3edKecpQkvfpLZAm5h/uAPlxbQ9imACHsus/fmvCEzy5giJ8vhqRcHn3nWw1mogHFEcnGMHY96QtmS6Nw+SL/VcFIK6D6lRAT0h6zPxrzZ3OaMj1b6FdGA= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1631.eurprd08.prod.outlook.com (10.168.66.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Mon, 11 Mar 2019 12:52:02 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65%11]) with mapi id 15.20.1686.021; Mon, 11 Mar 2019 12:52:02 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: draft-ietf-oauth-pop-key-distribution-05 Thread-Index: AdTYCRNQ6qf1pvhRQ/uCw2jzQrhEKA== Date: Mon, 11 Mar 2019 12:52:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.92.123.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1e37f400-0f41-409a-af1b-08d6a6205b95 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1631; x-ms-traffictypediagnostic: VI1PR0801MB1631: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1631; 20:u92tyyD0XWxkMEo+SQev5y+AGU/vWrovMq1weZwo7vOVouoycUBm8DwcKVUgujjeBg0LLIU1Q3Nd201Vb6bhsFiZzotsUh/6+ib6121cruxtod8Cip9nok+SH6gDTuOkQVbcbrZj0MQM5BxkYFq4sA8ec1rbEAAb43ZsJmJf+u0= x-microsoft-antispam-prvs: x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(346002)(376002)(396003)(39860400002)(189003)(199004)(40434004)(316002)(102836004)(68736007)(99286004)(8936002)(6506007)(26005)(4744005)(2906002)(5660300002)(7696005)(33656002)(25786009)(7736002)(74316002)(86362001)(72206003)(105586002)(14454004)(478600001)(106356001)(5024004)(53936002)(8676002)(81166006)(81156014)(66066001)(186003)(6916009)(55016002)(790700001)(6116002)(9686003)(54896002)(6306002)(52536013)(71190400001)(97736004)(71200400001)(3846002)(6436002)(476003)(486006)(14444005)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1631; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: N8Hz///2lLiNbR7eOUvy6k7f5lYwH/eMOzs4tjitXapWa2DJwgmMHM7mPGfNbMCLciWsZ1yqabZcHOVKwVgnZQpLp7DLK8bEHkqErhStvUMg1A7wJUaiDB9ZGqzI+cZ42OHcMy8+ItPknWGPAlbNrpXqU/mhxknzrsCBw1PqN6csDPg2oZvhga4ZGicBd7m8X+eHtwG9kGHTXpHcL1O1xi27P7lg4EEehacCzZeitsRXyFqYlVGopRfiU45tz6/rzoY+Tqox07+Fv8KKumEHfLZs3f9woJlkOM6zqlsCiAJOsBclLGeFd48X6UD9/DRNRKeErMHGMiM/KXOmpeU93al+Y3gQq2AF4+NpzvckZLAPBWRtxl9OWZC9hgC48Lahs9/ZAn+Hp/p5wMzGF+cTpc1uZlOEWRubBe8IMGFsuZI= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21124C1555ADD592EDB4B214FA480VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1e37f400-0f41-409a-af1b-08d6a6205b95 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 12:52:02.3783 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1631 Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 12:52:21 -0000 --_000_VI1PR0801MB21124C1555ADD592EDB4B214FA480VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just submitted -05 of the draft. The updates are limited to author info u= pdates and minor editorial nits. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21124C1555ADD592EDB4B214FA480VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just submitted -05 of the dra= ft. The updates are limited to author info updates and minor editorial nits= .

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21124C1555ADD592EDB4B214FA480VI1PR0801MB2112_-- From nobody Mon Mar 11 06:27:10 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA85F1277D8 for ; Mon, 11 Mar 2019 06:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cZeSriNMy_Xu for ; Mon, 11 Mar 2019 06:27:07 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4983C129AA0 for ; Mon, 11 Mar 2019 06:27:07 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id p17so3979013iol.7 for ; Mon, 11 Mar 2019 06:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=czkQw6X88/BT4HcKMGjcpEZVs1g4FT1QpqVL2w1Odn4=; b=VGD852y4v0v0bJ1S0cq82/h1tn90YfC4o3oCiQv1FMlAh/RQthkJ2Uy9lwEtuBBklB gZNoSeBNWo7U6MkW7ReXsauuB6aMelWLgr41BBRslFRwEokID25mmTOK17uV/uRxrv+X TAMcQ+lJ7YjwtxrkdertmKc8m2L+veogpAQTJqVwsCbp2mHpOT2Jfpf8HCmShKM4Q3tr +I7ah2aPd/SEy9rFNkxkle9mWyIBB/unqGWEuUJvCHV0XeIQJp+eXjZ4B+vuznYxkjcX jK9n+FAOPqBJiE2sqNnUS8fLhJsHOn4SBwi2v89fqFVFzX1hkC2TORs4hn9WjOuGi6DZ 4ukg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=czkQw6X88/BT4HcKMGjcpEZVs1g4FT1QpqVL2w1Odn4=; b=aynml7MMpde2dG9gfqyVmZNnRLs1I+tsHYGCrvAPIkjQ6J88mjQ6CxBAJfeP7BGgRa OtSHTV4azq8rFXVQjzJ8jMcBLGOdj77njirmT1BI2wz9PSfE3L2n23ABo8nuZMA2i0f4 6IBYIdmHQtrV0SNm42lqp1pjuOZb0jL4ObWQUje+OITHqd8u9Ir8h2VMX2aRquk6UKok UqHUn0zx8uCxvjctDbXiRHjpvMw3IqNxAv85dn8SYUfiMbxZ0MYlL8SLGNxWiy3Beeeh tCyqBRgXJhQ8n7ahn8rvAwUTS8B0c4AMEu09+RltGKurp0SSZNpJXQeqGG+ZoOfPzLPD 9eVA== X-Gm-Message-State: APjAAAUC1Gquopab+V5rq8grd88ymgDqqav8lgQ3JWsmRwhdoLshKp01 XkTg+EY/9bBDrw8/0fHw5jTEJHQO6TV3c5/rYD9KGzDu X-Google-Smtp-Source: APXvYqxoNQLPK/3aeSahBEQxm46BhdLgRbGeFWe7io+Q+Vdz1KsH17DywjxKt6GZKAqq4nZm84c6uL9YHkdJC3JORdc= X-Received: by 2002:a5d:8489:: with SMTP id t9mr18340141iom.0.1552310826479; Mon, 11 Mar 2019 06:27:06 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 11 Mar 2019 09:26:55 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000064b30b0583d18711" Archived-At: Subject: [OAUTH-WG] OAuth WG Virtual meeting this week X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 13:27:09 -0000 --00000000000064b30b0583d18711 Content-Type: text/plain; charset="UTF-8" All, The meeting time for this week has not changed, which means it will be one hour later for people that moved to Daylight Savings Time (1:00pm Eastern Time). Regards, Rifaat --00000000000064b30b0583d18711 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

The meeting time for this week has= not changed, which means it will be one hour later for people that moved t= o Daylight=C2=A0Savings Time (1:00pm Eastern Time).

Regards,
=C2=A0Rifaat

--00000000000064b30b0583d18711-- From nobody Mon Mar 11 06:37:31 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5941277D8; Mon, 11 Mar 2019 06:37:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <155231144978.23050.17841259546883608773@ietfa.amsl.com> Date: Mon, 11 Mar 2019 06:37:29 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 13:37:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution Authors : John Bradley Phil Hunt Michael B. Jones Hannes Tschofenig Mihaly Meszaros Filename : draft-ietf-oauth-pop-key-distribution-06.txt Pages : 17 Date : 2019-03-11 Abstract: RFC 6750 specified the bearer token concept for securing access to protected resources. Bearer tokens need to be protected in transit as well as at rest. When a client requests access to a protected resource it hands-over the bearer token to the resource server. The OAuth 2.0 Proof-of-Possession security concept extends bearer token security and requires the client to demonstrate possession of a key when accessing a protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 06:39:14 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2865F13109F for ; Mon, 11 Mar 2019 06:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 1B68qk53fkOH for ; Mon, 11 Mar 2019 06:39:05 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70044.outbound.protection.outlook.com [40.107.7.44]) (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 ECA5413104A for ; Mon, 11 Mar 2019 06:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pdRAZ6/vQquZiLTeHe3zkjOEJpthsLfglwodW6TB9Uo=; b=DqhASrKTA/EmTlCOdv8I4ZCx9MkJJ+izXg2DqAgG+jfKDHTXAcQXQ3yp9vuXu9NWAVbPss3aTsi2aAkVnud1IC13s4XKAX0yOS+9tLX7o0D+cBLJvkz6GU6P9YL4Yc2ernRJ/QxyjIstjxVA/QY7yWcKEZI7tci6fwZbGNr5g1Q= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1982.eurprd08.prod.outlook.com (10.173.74.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Mon, 11 Mar 2019 13:39:02 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65%11]) with mapi id 15.20.1686.021; Mon, 11 Mar 2019 13:39:02 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: draft-ietf-oauth-pop-key-distribution-06 Thread-Index: AdTYD64cJuF3kEgaSCapx171YlrkEw== Date: Mon, 11 Mar 2019 13:39:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c20511e0-0c01-432b-e131-08d6a626ec5e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1982; x-ms-traffictypediagnostic: VI1PR0801MB1982: x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1982; 20:0t1u8AGkeRz1MpM4Cwkyk9HOkqwfobsBguS3BGkoDXmejcXSkmcNjzWvC0Lh3awR4R6jl5FVnJf0fqPaaCv57ln7TM0u1CJI5iwNHkHbAXqZtfgjzYOn+GlI5uKqYjDkdCRAj24prR5l6LBzdu4HhxF5W1Rw5fGuyj6k+MhuI8U= x-microsoft-antispam-prvs: x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(396003)(366004)(136003)(40434004)(189003)(199004)(3846002)(86362001)(6116002)(476003)(486006)(790700001)(316002)(55016002)(14454004)(5024004)(256004)(14444005)(52536013)(81166006)(81156014)(105586002)(25786009)(106356001)(71200400001)(71190400001)(26005)(72206003)(97736004)(54896002)(53936002)(6916009)(9686003)(6306002)(186003)(2906002)(5660300002)(68736007)(6436002)(7696005)(8676002)(66574012)(33656002)(7736002)(99286004)(478600001)(8936002)(74316002)(66066001)(6506007)(53546011)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1982; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PZW66bNGRjDrAiMfkuW+y1zVzWEWsxriFcdqqGbH1VuYbvGHoSIPWwdyhtrxRWCEvOLb6WdVuuWiSMh+871faSkIQTVBG7M39EddMwvzyIlXz7DOtbObHDPBsk70ckGZFcWjOEtzS9443PzrU7UsgTX0KFFwZhqkujspyAwcOUWslvqzKVVmY7REC921lcHIiMkWKdB1g/r1O451A5hHdEmBALuYpTvh4ZqubLnop8SzGD7YUmt3k0WbvwAqVJH2swTj6fXni2WccN/0DRyBxDLBVu1yHbhRss8v+6JMi8K3xVwg+jtBFFlgM9E3sEmz57Dwu1jaEm2v4jnQGAfoHXyEhJ0dhny6hO12ZiTw5XUaahui/23mg+v9PKsCB7el9LMWCHK3vMmlg4iG4Xw8x0zdmhuRwF1lk7Mv7ackYrU= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21124702D1C8945FA7B9E3FEFA480VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: c20511e0-0c01-432b-e131-08d6a626ec5e X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 13:39:02.3022 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1982 Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 13:39:12 -0000 --_000_VI1PR0801MB21124702D1C8945FA7B9E3FEFA480VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well. I made a mistake with version -05. Now there is a version -06.... Ciao Hannes From: OAuth On Behalf Of Hannes Tschofenig Sent: Montag, 11. M=E4rz 2019 13:52 To: oauth Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-05 I just submitted -05 of the draft. The updates are limited to author info u= pdates and minor editorial nits.. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21124702D1C8945FA7B9E3FEFA480VI1PR0801MB2112_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well. I made a mistake with version -05. =

Now there is a version -06….

 

Ciao

Hannes

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Montag, 11. M=E4rz 2019 13:52
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-05

 

I just submitted -05 of the dra= ft. The updates are limited to author info updates and minor editorial nits= ..

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21124702D1C8945FA7B9E3FEFA480VI1PR0801MB2112_-- From nobody Mon Mar 11 07:01:38 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52831277D8 for ; Mon, 11 Mar 2019 07:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CzVK_67ia8f8 for ; Mon, 11 Mar 2019 07:01:31 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431AE130F3E for ; Mon, 11 Mar 2019 07:01:31 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id v62so3995602otb.3 for ; Mon, 11 Mar 2019 07:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=OyYGXgFmQEes+H9+SOO6BFSuEQpfko/Ay+GBd7TZBOI=; b=vF1e40FSl+xTPsCbe23967iS+784fWVKk1ozVDAiMLAVGJfUveukftfPE/zEpL07La NKYnBAYa+h5DNQGb+d5XExjIFuqZNf2Zm+/N05R2u1VHSjTCyu9NmPJiIyRjhA+84WAn jnDyoWGrfoIMHX3K7Ii7/7eaxqrIl48cFjordq9VwPWW+I9uzkQLPbAU+YlFW6iQEp4j SYjY7RLGd3xooZneG5iBUmLThFijws0BxVPFmDqeB33w5vQMqMhuFEA9l1mu/SJMJmhQ W/0RakYMd2tFbwfrXYQI/7bxTWk9oWiGckz2iYeQ3E47Wof/hrV0nsHENMTZhwRAZ+5m 1lRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=OyYGXgFmQEes+H9+SOO6BFSuEQpfko/Ay+GBd7TZBOI=; b=FIV5NIAdWrXbF9aMa0dmaeW5J51jGjpyBkPcoBBhSgB5/7Yoz/V0KASc/oPDeaPndM dD24DY2YnRNH54r6bDv/hi3xKSJYtl8gN1w9GQ7jXUHEl0Ukis6x0wbCqZVC7opN2FQq G1bhFX7Mak1OegBzR1LMRD1oOIAiiIyXoVgjoGF3sidJCgu3dJy1/SU8DPJGE1e+wagK gRzpa/t050C/MFyqsIvzCZ21QvZ4si17E6EHqnQwwvlm66tfS8Z7YJ7VFjqoYIHi71TM Usd/CkMnH17Y6X+8guCJpqD25oaaiXkrlR0pZu9pM3XYa0LQU2wkCG0vEWdphLrxKU9/ jifA== X-Gm-Message-State: APjAAAUtnbOokzGIWIuU4t2fW0oXOSQLD12RUveBjYNfT+697reWepgH Z8l1yTxL36A9ZvjxnnAXMwVvDdlyQ4MD6zWJO/602Wye02Y= X-Google-Smtp-Source: APXvYqy4+eNQF9gUEJ4Kj0Lgbqv4hCzQVviu42pJMH+PdnKQbUPIPWtkHSD/gPaEu4A1AebbamtI3vkPGw3j1lMx9zw= X-Received: by 2002:a05:6830:1297:: with SMTP id z23mr22467263otp.257.1552312889980; Mon, 11 Mar 2019 07:01:29 -0700 (PDT) MIME-Version: 1.0 References: <6312173.9VWeF3DjuQ@papegaaij> In-Reply-To: From: Emond Papegaaij Date: Mon, 11 Mar 2019 15:01:19 +0100 Message-ID: To: OAuth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device flow error response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 14:01:37 -0000 Yes, that's how I implemented it as well. I return 'invalid_request' when the client_id is missing entirely. Do you have any thoughts how this specification should work in combination with other specs, such as OIDC? For example, the OIDC Authentication Request specifies several additional parameters, some of which may be applicable for the device flow as well. Can the device flow be used to obtain an ID token? How should parameters like 'max_age', 'id_token_hint' and 'claims' be processed? My plan was to construct a pseudo-authentication/authorization request using the parameters specified at the device authorization endpoint and apply these parameters during the user interaction. Some parameters, such as 'prompt=3D3Dnone', do not make much sense though. I think it may be a good idea to describe how this spec is supposed to interoperate with other specifications, especially those that extend the Authorization Endpoint. This definition can never be complete, as new specs will be defined after this one, but it can at least try to describe the general rules that apply. PS. Other specifications also define additional parameters that may be useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and 'include_granted_scopes' from OAuth 2.0 Incremental Authorization. Best regards, Emond Papegaaij Topicus KeyHub On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell wrote: > > While probably not terribly important from an interoperability perspectiv= e, I agree that does seem like an omission. > > I took a quick look at our implementation and bad requests to the device = authorization endpoint will indeed return what is a standard OAuth 2.0 erro= r response normally from the token endpoint with invalid_client or invalid_= scope error codes. And a little bit of poking at Google's device authorizat= ion endpoint suggests it behaves similarly. I suspect it's pretty typical. > > > > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij wrote: >> >> Dear all, >> >> I'm working on an implementation of the OAuth 2.0 Device Flow for Browse= rless >> and Input Constrained Devices and noticed a possible omission in the spe= c. >> Section 3.2 describes the Device Authorization Response, but only the su= ccess >> response is specified, not the error response. I would have expected a >> standard OAuth 2.0 error response, probably with the following error cod= es: >> invalid_request, invalid_client and invalid_scope. >> >> Best regards, >> Emond Papegaaij >> Topicus KeyHub >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer= . Thank you. From nobody Mon Mar 11 09:04:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDB8131191 for ; Mon, 11 Mar 2019 09:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 w-UKQtu5BqEe for ; Mon, 11 Mar 2019 09:03:59 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D21D131148 for ; Mon, 11 Mar 2019 09:03:58 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id b6so4514412iog.0 for ; Mon, 11 Mar 2019 09:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=Nc2Wo8NL6egZVgVLg51n2y+bI5qnc4ZcVuffyRayKCM=; b=Ika+jvI1cta0yc19Jymwx5FEsDcmc2sX42aFhgG8o8inY4LIFZu71jtB38bcW1hcrK hLXZqLQWDTim7Pg9xX8lgxSrXLoIdokM0x+PDm3We8ITFm+oi0YYamDLjHpPnF92h37G x2aZy6n9NW07F8ypsnWVz4TJLlNKQt74tBDSM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Nc2Wo8NL6egZVgVLg51n2y+bI5qnc4ZcVuffyRayKCM=; b=grrQxVxXdg1sUIr9D34etwZtN2jhSlRr8+hqsjufyvJB1bGZ7uFyNBxMDp3EpvcA0R wGUsSSF48PBxQWyUTAlShuB0gOL0nxpVbKV/YUD0qhyTX6Ye2XXmUxPaej9MMxeRyiRu fieKNJU2HIBuWpUUUZnDKwPtsnPakfmEiFmhL2KhWakKn57aTl1aHPnfKTNTnw3Kl2l4 +kbbPn4Y/9wZMtG/PUHlzifuTbk5VZ7DggiH/gOQIqWbUx1cFedC6DLkoVwB/TrJmngJ 9nHd+2hYFr7N4NNFaAYzXVv7wqDwoCc+/UCkFrzy+VT+gxddU2lzoIxDWuK8NH/Z9Oke LspQ== X-Gm-Message-State: APjAAAVKg2T545d+gKDS5iZk403GCaHOtQpdNbX4oDMEDjvNGPD2LTjB Q9pqFACxYLtV7ggnnrorxXqNH6HavXy5avUOntRrvBkzXLRHFmrFZWUVBUMQP/UlFdwSVCc1wpw kMjcux8bHRMgPx/hiZ6s= X-Google-Smtp-Source: APXvYqzYy6v639H0Hfg1WeLG3M3FRZpk6w8p+iI84K1RvdjJa7wzGE6auIReD4Hlhg3Hulwk18kE/6T8VeLVbD6Z1ZY= X-Received: by 2002:a5d:8190:: with SMTP id u16mr18572132ion.238.1552320237142; Mon, 11 Mar 2019 09:03:57 -0700 (PDT) MIME-Version: 1.0 From: Brian Campbell Date: Mon, 11 Mar 2019 10:03:31 -0600 Message-ID: To: oauth , William Denniss , John Bradley , Mike Jones , Hannes Tschofenig Content-Type: multipart/alternative; boundary="0000000000005029f40583d3b8bd" Archived-At: Subject: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:04:07 -0000 --0000000000005029f40583d3b8bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Another omission[1] (maybe, I believe it is anyway) to the Device Flow is that client authentication isn't defined for the device authorization request to device authorization endpoint. I suspect that it's largely an oversight because public clients are really the conical use-case for the device flow and no authentication is needed or possible in that case. There are, however, likely to be cases where a client with credentials will do the device flow and it would be good for the AS to be able to properly authenticate such clients before setting up and saving the state for the transaction. Having normal client authentication at device authorization endpoint also brings better consistency to client identification/authentication for requests made directly from client to AS. [1] error responses from the device authorization endpoint should probably also be defined https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4 --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000005029f40583d3b8bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another omission[1] (maybe= , I believe it is anyway) to the Device Flow is that client authentication = isn't defined for the device authorization request to device authorizat= ion endpoint.

I suspect that it's largely= an oversight because public clients are really the conical use-case for th= e device flow and no authentication is needed or possible in that case. The= re are, however, likely to be cases where a client with credentials will do= the device flow and it would be good for the AS to be able to properly aut= henticate such clients before setting up and saving the state for the trans= action. Having normal client authentication at device authorization endpoin= t also brings better consistency to client identification/authentication fo= r requests made directly from client to AS. =C2=A0


[1] error responses from the device authorization endpoint= should probably also be defined https://mailarchive.ietf.org/arch= /msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4

=

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000005029f40583d3b8bd-- From nobody Mon Mar 11 09:07:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAAD127985 for ; Mon, 11 Mar 2019 09:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 iKUddn0kah8d for ; Mon, 11 Mar 2019 09:07:54 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5EE113111D for ; Mon, 11 Mar 2019 09:07:47 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id y6so4493251ioq.10 for ; Mon, 11 Mar 2019 09:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6jQKGjuf/Qjw8M0dXul90RSn0TcZJAxL2p7Ngb/DiiM=; b=lXvbpahpzkmzub3M4qzbhDnHDpQNhWYEw5R54rz2kLuxRl5Zvhr1KD5UJmrIRXtdB9 lvv58nqqroOtro459/iI41On0Pf1ygMi7FWvEkI9FlMeMsVoC+vb+mOQE1suuZOZsVY1 dUH/T3KsihPUfI+QVxvQsO12f+8ZiF+L9yto8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6jQKGjuf/Qjw8M0dXul90RSn0TcZJAxL2p7Ngb/DiiM=; b=M9irh8tIMPGHKnnSrPv8Nl5gmpGA1H7g9P8Fet5DN53oo3xqtgeQ7/9fj9VMlFshxe kuFGep47Kj6RguP0ZDl6qcn9Sotln7hOFHBCGSKpdGwxZbMLK6h/PdpftlGivwDwelHA naWTx+y0yXCp+ODz71I/dQoePYmRNo/Z0MqE9RQOezvcoK21XuFFzpu0dq6eLYd9tDXV wPKGb/4KujbJoRQ93lRx8+LW2GFzFqJroQ68xROfzWYwvoxzvDUyRAl4XWkFWE4h9mi1 doOMkTMOa75cH8OY4Z7xKAkZ4vFEZHaZxc92NE34TpzVfhDmv+swZnxBrmyr+uDLPL89 EDAA== X-Gm-Message-State: APjAAAVUN6tupV3a5GjXyAyE/xlFXzHF509aoq2p2yGmQ6pVt4q2sDQd VKozj/MavuISbo0j8LAe2FE7JoS6o7r+VoRiRVfq1fLP19biftWGVgw70+63bnSpDSTTjyirQSi vtaemIsFlSiOm1ggV X-Google-Smtp-Source: APXvYqzq86Psj9CSR4z64ENwtKlwVXBGsJAoB5alqGol4oe9iLy1E3NosTRfsB/+ntY4T27dFzXU2rFZuWi9FeLowIg= X-Received: by 2002:a5d:8190:: with SMTP id u16mr18585450ion.238.1552320466821; Mon, 11 Mar 2019 09:07:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 11 Mar 2019 10:07:20 -0600 Message-ID: To: oauth , William Denniss , John Bradley , Mike Jones , Hannes Tschofenig Content-Type: multipart/alternative; boundary="00000000000000b6e90583d3c624" Archived-At: Subject: Re: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:07:57 -0000 --00000000000000b6e90583d3c624 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I do realize it's very late in the process for this document but believe these omissions can be addressed in the document with only minor changes/additions and that it'd be better late than not at all. On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell wrote: > Another omission[1] (maybe, I believe it is anyway) to the Device Flow is > that client authentication isn't defined for the device authorization > request to device authorization endpoint. > > I suspect that it's largely an oversight because public clients are reall= y > the conical use-case for the device flow and no authentication is needed = or > possible in that case. There are, however, likely to be cases where a > client with credentials will do the device flow and it would be good for > the AS to be able to properly authenticate such clients before setting up > and saving the state for the transaction. Having normal client > authentication at device authorization endpoint also brings better > consistency to client identification/authentication for requests made > directly from client to AS. > > > [1] error responses from the device authorization endpoint should probabl= y > also be defined > https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4 > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000000b6e90583d3c624 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do realize it's very late in the process for this do= cument but believe these omissions can be addressed in the document with on= ly minor changes/additions and that it'd be better late than not at all= .

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
<= /div>
Another omission[1] (maybe, I believe it is = anyway) to the Device Flow is that client authentication isn't defined = for the device authorization request to device authorization endpoint.
=

I suspect that it's largely an oversight beca= use public clients are really the conical use-case for the device flow and = no authentication is needed or possible in that case. There are, however, l= ikely to be cases where a client with credentials will do the device flow a= nd it would be good for the AS to be able to properly authenticate such cli= ents before setting up and saving the state for the transaction. Having nor= mal client authentication at device authorization endpoint also brings bett= er consistency to client identification/authentication for requests made di= rectly from client to AS. =C2=A0


[= 1] error responses from the device authorization endpoint should probably a= lso be defined https://mailarchive.ietf.org/arch= /msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4

=

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000000b6e90583d3c624-- From nobody Mon Mar 11 09:14:44 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70D312008A for ; Mon, 11 Mar 2019 09:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 t-hDCEpm95zK for ; Mon, 11 Mar 2019 09:14:39 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FC41278CF for ; Mon, 11 Mar 2019 09:14:39 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id b3so4444476otp.4 for ; Mon, 11 Mar 2019 09:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UAW9aYukGxpft8GwW0wxrpdloxMKkYeI/tG79OOTxFA=; b=boXf8ggZ4VJKXZ6j1NQhqk6adub5xhHl+gF3P8hTTtNifs9EfD8WwgStdw6+476mkN kTpgIcjcqpe7EQ7NMf027uilwQdbbSfG8HxoC/g3a0dCdbSskej0sIdPPSpGG61vq+rQ lmfiGLTM9DEn+IQrtBFndtlU+C8oWMwqLT88dUnlRJS/vNuMVcbiKMfiaKwag5YhX2n9 w5DlLoh79juH5CaOsuxUY6Niqr2tdiWXvAdGb7H9i+EnVitaGhIqWDsjvJOJW+xKKdNe YiIb1O+EF9NER/YMqiSdnPfjcCODhf1yvY/uo+cRyceEu3SKKV3QD8TZPkb0xAr4YEwY If0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UAW9aYukGxpft8GwW0wxrpdloxMKkYeI/tG79OOTxFA=; b=STbQjEHKgcJUgI9VuKt4bAyADmTMDir9m4TqGyNbHmkUjLbZZbnC9jFSXXPr86bLGK LTZz23y3h0CZX3NCe5wO7Ikw6KumpH6Fugj2pjO4wO3NdS8x3HJ/pAIUrVsq8fcf4Zxv fb/24f+2Dqgua2TPUaIPFyzB6GOejKv7wH7ld9Q0V6IkTUDVcDBJx/lZs1rZ5gk0C1ew qvce7+B5w7eqpm4bAbFu9Yy20m8oTY/vKruHT2ZHzms8qRNcfSQy0GHQN6MQtiuNvZYE K94cXK93k0bH8aiAt+vqJUmUTpvIVyGrTDIgwLTpEE6Iz98IJV9A7afqIWmMLS9O8NRh IM3w== X-Gm-Message-State: APjAAAUxEiSj2T5nOHL4NYKuebO08HKXpg2Qlju+oJXmG2TV1r/eQmd3 N6Wg7QEuC5mXczigT7ILtdWAFiemcA1LaWqXJg== X-Google-Smtp-Source: APXvYqw6ugGuxbCs4Te340RpE9SwU2/5SFYDWg1dIkvEdXpXekVJALU/nJo2oJ18Dqk0ezD/ki2yfb+4MKLHIHsAogU= X-Received: by 2002:a9d:6195:: with SMTP id g21mr20564054otk.76.1552320878058; Mon, 11 Mar 2019 09:14:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Mon, 11 Mar 2019 17:14:27 +0100 Message-ID: To: Brian Campbell Cc: oauth , William Denniss , John Bradley , Mike Jones , Hannes Tschofenig Content-Type: multipart/alternative; boundary="000000000000839fd80583d3de4a" Archived-At: Subject: Re: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:14:42 -0000 --000000000000839fd80583d3de4a Content-Type: text/plain; charset="UTF-8" If we're about to add client authentication for the device_authorization_endpoint, i'd say we should also register for device_authorization_endpoint_auth_method, device_authorization_endpoint_auth_signing_alg client metadata. Maybe define the default value to be "none" / not provided to be in line with the late draft implementations. Wdyt? S pozdravem, *Filip Skokan* On Mon, 11 Mar 2019 at 17:08, Brian Campbell wrote: > I do realize it's very late in the process for this document but believe > these omissions can be addressed in the document with only minor > changes/additions and that it'd be better late than not at all.. > > On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Another omission[1] (maybe, I believe it is anyway) to the Device Flow is >> that client authentication isn't defined for the device authorization >> request to device authorization endpoint. >> >> I suspect that it's largely an oversight because public clients are >> really the conical use-case for the device flow and no authentication is >> needed or possible in that case. There are, however, likely to be cases >> where a client with credentials will do the device flow and it would be >> good for the AS to be able to properly authenticate such clients before >> setting up and saving the state for the transaction. Having normal client >> authentication at device authorization endpoint also brings better >> consistency to client identification/authentication for requests made >> directly from client to AS. >> >> >> [1] error responses from the device authorization endpoint should >> probably also be defined >> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4 >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000839fd80583d3de4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If we're about to add client aut= hentication for the device_authorization_endpoint, i'd say we should al= so register for device_authorization_endpoint_auth_method, device_authoriza= tion_endpoint_auth_signing_alg client metadata. Maybe define the default va= lue to be "none" / not provided to be in line with the late draft= implementations. Wdyt?

S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= > wrote:
=
I do realize it's very late in the process for this do= cument but believe these omissions can be addressed in the document with on= ly minor changes/additions and that it'd be better late than not at all= ..

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <bcampbell@pingidentity.com<= /a>> wrote:
<= div dir=3D"ltr">
Another omission[1] (maybe,= I believe it is anyway) to the Device Flow is that client authentication i= sn't defined for the device authorization request to device authorizati= on endpoint.

I suspect that it's largely = an oversight because public clients are really the conical use-case for the= device flow and no authentication is needed or possible in that case. Ther= e are, however, likely to be cases where a client with credentials will do = the device flow and it would be good for the AS to be able to properly auth= enticate such clients before setting up and saving the state for the transa= ction. Having normal client authentication at device authorization endpoint= also brings better consistency to client identification/authentication for= requests made directly from client to AS. =C2=A0



<= /div>

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000839fd80583d3de4a-- From nobody Mon Mar 11 09:22:05 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3113110F for ; Mon, 11 Mar 2019 09:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 56yJXxwuWL4y for ; Mon, 11 Mar 2019 09:22:01 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C521278CF for ; Mon, 11 Mar 2019 09:21:26 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id w66so4125278oia.4 for ; Mon, 11 Mar 2019 09:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kLlsPifHufF0JOATJeBqoqod9xP4h8k3Q/Ejz6Lr/Lw=; b=Ajr28FW2OhW4iYVCZnRw4Wob1b2rWv8XU5uIownBD34H5P0TAta8NE7GgTaguVziEk 0aqc/Cgj87Za1hIlgdv7Opc5ucGIYzmPoHEgwr4hnM8O0qYm0YSL00Gwr4O4/fN97gh/ eP+ZOi0FCuOk5PcA+wNhmV65CKv3Wv39LIpw4+hfDlI50qPPWP3Ls6AfTa7fKmZkSX/+ LTtjjKAdxTsWRS8GdTavEZweqBdZesGGUvz5Dg90F5WAJjpRKju66vYRwrQMO4ConfyQ xjL9Y1QOQx4xaOMo/8plLi9j6NoY+Ax0aT0kik8M1jl6vRNbpaESL/6xWKEH+O2o6TxV wEzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kLlsPifHufF0JOATJeBqoqod9xP4h8k3Q/Ejz6Lr/Lw=; b=s1cPRKdSJVrbEYCESX7BY6wiGC6tPIBvQRTLJHCfAeIjh6Y06cE6mMh+AG3TMS50M/ 5BhSAbdlaZo1etdOMylF10OJnYCzwVam1JPMTty9oIWPejTomYx3pr5pUrdYxPZAVpVJ Xkz+9eDQMxK3jazEhNbLHHtmmPvolGHAnstrXhYzItua9aYJlAsd9v2WmeGxcDcFyqUA sH1hiU5QEiVd8DVoIVB07Lrg6PjP/eRees34rRcsFWN3axcs6wVaTtj0ApVXKBC80m2L 5QeA5LOMfjC8bhxGuiqeyaCtUfIj94WydrgmCUVwXPuNLv1vv9Clbi4NEtYk8EvuIICr vRgA== X-Gm-Message-State: APjAAAWbInfqqr/mojcEc/kBY+x7CFd+XSMUiYTYpqsLlgo7wx7Swp2p S6KL5SrPzPTqkMy2fa9uNd9sLYa9DjonsSVqUw== X-Google-Smtp-Source: APXvYqw7gEcNcY9Bu8qq+MgMVmRBFLl62wozeM6gogCE4Koz/ye3bcynAULfiVIe4dKPKUV32l+N2E/ubDZB9RFCA1Y= X-Received: by 2002:aca:af83:: with SMTP id y125mr324919oie.174.1552321285225; Mon, 11 Mar 2019 09:21:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Mon, 11 Mar 2019 17:21:14 +0100 Message-ID: To: Brian Campbell Cc: oauth , William Denniss , John Bradley , Mike Jones , Hannes Tschofenig Content-Type: multipart/alternative; boundary="000000000000c884810583d3f627" Archived-At: Subject: Re: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:22:04 -0000 --000000000000c884810583d3f627 Content-Type: text/plain; charset="UTF-8" Strike that, it should maybe just use the registered auth method for the token endpoint? If there's auth we should also make it clear that client_id should not be omitted from the request body and it must be the same as the one provided with client authentication. S pozdravem, *Filip Skokan* On Mon, 11 Mar 2019 at 17:14, Filip Skokan wrote: > If we're about to add client authentication for the > device_authorization_endpoint, i'd say we should also register for > device_authorization_endpoint_auth_method, > device_authorization_endpoint_auth_signing_alg client metadata. Maybe > define the default value to be "none" / not provided to be in line with the > late draft implementations. Wdyt? > > S pozdravem, > *Filip Skokan* > > > On Mon, 11 Mar 2019 at 17:08, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> I do realize it's very late in the process for this document but believe >> these omissions can be addressed in the document with only minor >> changes/additions and that it'd be better late than not at all.. >> >> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> Another omission[1] (maybe, I believe it is anyway) to the Device Flow >>> is that client authentication isn't defined for the device authorization >>> request to device authorization endpoint. >>> >>> I suspect that it's largely an oversight because public clients are >>> really the conical use-case for the device flow and no authentication is >>> needed or possible in that case. There are, however, likely to be cases >>> where a client with credentials will do the device flow and it would be >>> good for the AS to be able to properly authenticate such clients before >>> setting up and saving the state for the transaction. Having normal client >>> authentication at device authorization endpoint also brings better >>> consistency to client identification/authentication for requests made >>> directly from client to AS. >>> >>> >>> [1] error responses from the device authorization endpoint should >>> probably also be defined >>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4 >>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited.. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.*_______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --000000000000c884810583d3f627 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Strike that, it should maybe just use the registered auth = method for the token endpoint?

If there's auth we sh= ould also make it clear that client_id should not be omitted from the reque= st body and it must be the same as the one provided with client authenticat= ion.

S pozdravem,Filip Skokan


On Mon, 11 Mar 2019 at 17:1= 4, Filip Skokan <panva.ip@gmail.com> wrote:
If we're abou= t to add client authentication for the device_authorization_endpoint, i'= ;d say we should also register for device_authorization_endpoint_auth_metho= d, device_authorization_endpoint_auth_signing_alg client metadata. Maybe de= fine the default value to be "none" / not provided to be in line = with the late draft implementations. Wdyt?

S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcampbell=3D40pingidentity.co= m@dmarc.ietf.org> wrote:
I do realize it's very late in the pro= cess for this document but believe these omissions can be addressed in the = document with only minor changes/additions and that it'd be better late= than not at all..

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <= bcampbell@p= ingidentity.com> wrote:
Another om= ission[1] (maybe, I believe it is anyway) to the Device Flow is that client= authentication isn't defined for the device authorization request to d= evice authorization endpoint.

I suspect that = it's largely an oversight because public clients are really the conical= use-case for the device flow and no authentication is needed or possible i= n that case. There are, however, likely to be cases where a client with cre= dentials will do the device flow and it would be good for the AS to be able= to properly authenticate such clients before setting up and saving the sta= te for the transaction. Having normal client authentication at device autho= rization endpoint also brings better consistency to client identification/a= uthentication for requests made directly from client to AS. =C2=A0


[1] error responses from the device author= ization endpoint should probably also be defined https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c884810583d3f627-- From nobody Mon Mar 11 09:31:44 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7BB1286E7 for ; Mon, 11 Mar 2019 09:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 5EqdFO5q7yvv for ; Mon, 11 Mar 2019 09:31:39 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08419127963 for ; Mon, 11 Mar 2019 09:31:39 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id l15so8264404iti.4 for ; Mon, 11 Mar 2019 09:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ugKLxYbt8w9NpjDQZaxjRd4jD3ImEKM4SPGyoOmw7LE=; b=Xt+8KQPZ3QkWBDAahCSXg1xuoHQMA9xnDKhhK+pwuMnimdtzLyCHBoeVJR8U7SOf2a M0saad1eqG5CE9cgAuUo6mtiIH9st4G9yDbSVIiMfrX5Ls8MJ/zWIfwqgV1Ru9CDuIH+ 21pmqehrp6O2A6DS5E9hI1+wUNZrgEVTt7n5k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ugKLxYbt8w9NpjDQZaxjRd4jD3ImEKM4SPGyoOmw7LE=; b=uWzF4GsZuMz5LY+lklZQ6ZW2PnTpOWo3C/Ncs1kE1pwRp+cBO+T0QUWLHsmQN9qD5t O2YYmRF0LsVRfjJ4ns1sScwa7tI5ymEN+tXPaz5egMIuJzub4tcACCu4e3rQABqoihu9 bH562cKY6535hlHBUkrTdcUzQGt+s9/bl3xytiNKrzcE72cPeA13x3RmLeOCoS+sieFz Nad28v4YoFgm3bCKKgUJO9oASbs5C8flDBY6zkcJYjIjpB7le1/HNI2QDiFsb9CKkmRr e/jXXcFiwyYeDCRgjX7q8X/frYJU2UdcZXhkquESvg8giEnLBXJ+R+8vwtJVpmrhHzzc GDxA== X-Gm-Message-State: APjAAAXQdX//yYe+JAlZv1Fj85HsceZrAGAqFYFBQp9xDsKsPU6rC1L3 +KDzChmHMHm9l49Clu4g2NfBq50R5Qk70aPp3APOkR+UsxksKqx4JVH5jU5NPK36AnTC3yvSv5e QqSuRwKGnSlyptm59 X-Google-Smtp-Source: APXvYqyw2+7Wz8mXHcO2os8+m52qhhIjR7j8aEz7XJ51zgfWScWZ9tRf5mxIX6GTQ2otks119fcVHqTPqNJmQLTKze4= X-Received: by 2002:a24:b90d:: with SMTP id w13mr326025ite.45.1552321898195; Mon, 11 Mar 2019 09:31:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 11 Mar 2019 10:31:11 -0600 Message-ID: To: Filip Skokan Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="00000000000051c9060583d41b8e" Archived-At: Subject: Re: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:31:42 -0000 --00000000000051c9060583d41b8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan wrote: > Strike that, it should maybe just use the registered auth method for the > token endpoint? > Yeah, that's what I'd think would be the way to go. > > If there's auth we should also make it clear that client_id should not be > omitted from the request body and it must be the same as the one provided > with client authentication. > > Fair point. > S pozdravem, > *Filip Skokan* > > > On Mon, 11 Mar 2019 at 17:14, Filip Skokan wrote: > >> If we're about to add client authentication for the >> device_authorization_endpoint, i'd say we should also register for >> device_authorization_endpoint_auth_method, >> device_authorization_endpoint_auth_signing_alg client metadata. Maybe >> define the default value to be "none" / not provided to be in line with = the >> late draft implementations. Wdyt? >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Mon, 11 Mar 2019 at 17:08, Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >>> I do realize it's very late in the process for this document but believ= e >>> these omissions can be addressed in the document with only minor >>> changes/additions and that it'd be better late than not at all.. >>> >>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> Another omission[1] (maybe, I believe it is anyway) to the Device Flow >>>> is that client authentication isn't defined for the device authorizati= on >>>> request to device authorization endpoint. >>>> >>>> I suspect that it's largely an oversight because public clients are >>>> really the conical use-case for the device flow and no authentication = is >>>> needed or possible in that case. There are, however, likely to be case= s >>>> where a client with credentials will do the device flow and it would b= e >>>> good for the AS to be able to properly authenticate such clients befor= e >>>> setting up and saving the state for the transaction. Having normal cli= ent >>>> authentication at device authorization endpoint also brings better >>>> consistency to client identification/authentication for requests made >>>> directly from client to AS. >>>> >>>> >>>> [1] error responses from the device authorization endpoint should >>>> probably also be defined >>>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k= 4 >>>> >>>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly >>> prohibited... If you have received this communication in error, please >>> notify the sender immediately by e-mail and delete the message and any = file >>> attachments from your computer. Thank you.* >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000051c9060583d41b8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Mar 11, 2019 at 10:22 AM Fili= p Skokan <panva.ip@gmail.com&g= t; wrote:
Strike that, it should maybe just use the registered auth method= for the token endpoint?

Yeah, that&#= 39;s what I'd think would be the way to go.
=C2=A0
=
If there's auth we should also make it clear that client_id= should not be omitted from the request body and it must be the same as the= one provided with client authentication.

<= /div>

Fair point.

=

=C2=A0
S pozdravem,Filip Skokan


On Mon, 11 Mar 2019 at 17:= 14, Filip Skokan <panva.ip@gmail.com> wrote:
If we're abo= ut to add client authentication for the device_authorization_endpoint, i= 9;d say we should also register for device_authorization_endpoint_auth_meth= od, device_authorization_endpoint_auth_signing_alg client metadata. Maybe d= efine the default value to be "none" / not provided to be in line= with the late draft implementations. Wdyt?

S pozdravem,
Filip Sko= kan


On Mon, 11 Mar 2019 at 17:08, Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
I do realize = it's very late in the process for this document but believe these omiss= ions can be addressed in the document with only minor changes/additions and= that it'd be better late than not at all..

On Mon, Mar 11, 2019 at= 10:03 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
Another omission[1] (maybe, I believe it is anyway) to th= e Device Flow is that client authentication isn't defined for the devic= e authorization request to device authorization endpoint.
I suspect that it's largely an oversight because public cl= ients are really the conical use-case for the device flow and no authentica= tion is needed or possible in that case. There are, however, likely to be c= ases where a client with credentials will do the device flow and it would b= e good for the AS to be able to properly authenticate such clients before s= etting up and saving the state for the transaction. Having normal client au= thentication at device authorization endpoint also brings better consistenc= y to client identification/authentication for requests made directly from c= lient to AS. =C2=A0


[1] error resp= onses from the device authorization endpoint should probably also be define= d https://mailarchive.ietf.org/arch/msg/oauth/DM= TUR1msdNQPiLh0xVXe39933k4

<= /div>

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited...=C2=A0 If you have received this communication in e= rror, please notify the sender immediately by e-mail and delete the message= and any file attachments from your computer. Thank you._= ______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000051c9060583d41b8e-- From nobody Mon Mar 11 10:28:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91BE1311E2 for ; Mon, 11 Mar 2019 10:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com 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 oVqXSx4gXB0e for ; Mon, 11 Mar 2019 10:28:19 -0700 (PDT) Received: from sonic313-14.consmr.mail.bf2.yahoo.com (sonic313-14.consmr.mail.bf2.yahoo.com [74.6.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073B5131222 for ; Mon, 11 Mar 2019 10:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1552325281; bh=0rsl9uIIdfloCCRqb5zVWPAEEP5OcS8yW2WZVC2VFuo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=mHxKtNuaOvxTBd+8y5jEih28Wqf0zA192Z4vPHhJsOefquehVOA2fpcuw8bB0Gl64FCHCXQpvNpMXo2flTykO4quGai7LNmE3A/wkunQQN5mdm+lZyoOtFh1TOdOUGkMeS2P30KYuCzdrGMoAlDcTeitDmw3vYops2OyVUdaxZflR2SPxm3bVWGVehg+uuZdAGhrer94uXoxSW+0H4SgAk2LtiCPZ99mm2ArLrSc8Hy7ST50Bebdcpl1P968eOg5KX9XPlIwbe6Urjec6X65IDwK3f12qd0HY4t+3+X6XqVnPwThDxrEQ2qQjCU88ZnvC0mXAeyS7Y8UVo5/4PSr2A== X-YMail-OSG: BYdosswVM1nzhuzDgEMnVpjjFO8gt.QgD4fB9cYqWI7D20DEKyeUIDs7LXCvMBw k2mob.FCRS9tmu2CW9Auu1jxg16oHa8f_4kkL3huRGlgkc_9YZLDIcbG195_JIwqCQVJkdvEtBuv hl84r065L6qp65.yXaLxXzziqzxdxVeRLyFkmEGGun8mLUBFXM9Vf1NKumU0STtuHADBQRiciFn0 EAyBKYMJoN6aecycz4pEqENaOBdEJiwbt45Qx5Xvj9c.kGvXAiYs2usXBI0nvHoaM73flZH0qvDX FI.aXKDjas3NT1gYovS7utuC4ilIJgfWQ7NUgdGXhDKqvFAmNcp.3iiQmdBkZTe_Dd1PPFgoFwDW Y22lhsGYn.se1QK6vx6Yi3hWVCiRo6DmgTZCG1K2m5Efi3H_3FFrl_a1nqNAMN6GPKGOYAbDRKCv R3kM47_5D7fkoPE2zLBocwXamX2qs_O1BsqCklk5FJ5fnM9OnbvLdQXjPKo2Rpn_.ZJxwr5OOoej iLhPCKPx.IpL4JWYhDOqhD9vN4uZgOaJGAUCUXh3NicKo_JWMNuCAd.l5aWIBaNSBQ5sxO1yg.bi jHv3YKLAJJndtpxCrLiDpvHPIShhi1c5anQlXxan1q9AANSjJ1JL_5BcSpu95KU2G7kSEHuGX9Hc vSsmdGV59mvehPD0pc_2UJ2wSqKX60zu72A7NCODWyeEISeDhw1Ay0o.Gf2gKUos..7Mvl8ZZW29 6MarwNgHhQAm7R5lggcZQjQqCnnpB9jY7zqMgZSgNkb1eXiwoWnCaMIlACeymEtIh6ItKB241kTU vU3u_zzbcyOoMFGtwQyUQRXUUa9nZhh0SLHd.I7hzdgmi_CDy6hOLAHEw4h6x8h0xzfn3ioJ16Ib XdXTlLqhbfHDXptRHir8i6QooCioqbG151qFdXCw3Wa4UqQe3yDMRvO0Ir2n2l.Vsc4F2Gg1GN.L YBzh0CRVFdraOM.Rx0fK9J6Wn6JRXVUObHpcTv1Jtlqcq5v0Vzw5z1aTI5u5dspsXWo3wzaczbY1 pj6ytGBFmff37uLIHVj_H0bMNF5QIwU99pGJ8HdDQSQAs7Nijg32PelPyVqzppAm_c16s Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Mon, 11 Mar 2019 17:28:01 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp421.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ffc4b76c3c6fe1da92f100fb835d2e1a; Mon, 11 Mar 2019 17:27:58 +0000 (UTC) To: Brian Campbell , Filip Skokan Cc: oauth References: From: George Fletcher Organization: AOL LLC Message-ID: <7c605f52-ff7f-49cd-0a4e-af3aa15663be@aol.com> Date: Mon, 11 Mar 2019 13:27:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BB17FE73430CD844181DD091" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:28:24 -0000 This is a multi-part message in MIME format. --------------BB17FE73430CD844181DD091 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 to using the same client authn method as for the /token endpoint On 3/11/19 12:31 PM, Brian Campbell wrote: > > > On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan > wrote: > > Strike that, it should maybe just use the registered auth method > for the token endpoint? > > > Yeah, that's what I'd think would be the way to go. > > > If there's auth we should also make it clear that client_id should > not be omitted from the request body and it must be the same as > the one provided with client authentication. > > > Fair point. > > > S pozdravem, > *Filip Skokan* > > > On Mon, 11 Mar 2019 at 17:14, Filip Skokan > wrote: > > If we're about to add client authentication for the > device_authorization_endpoint, i'd say we should also register > for device_authorization_endpoint_auth_method, > device_authorization_endpoint_auth_signing_alg client > metadata. Maybe define the default value to be "none" / not > provided to be in line with the late draft implementations. Wdyt? > > S pozdravem, > *Filip Skokan* > > > On Mon, 11 Mar 2019 at 17:08, Brian Campbell > > wrote: > > I do realize it's very late in the process for this > document but believe these omissions can be addressed in > the document with only minor changes/additions and that > it'd be better late than not at all.. > > On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell > > wrote: > > Another omission[1] (maybe, I believe it is anyway) to > the Device Flow is that client authentication isn't > defined for the device authorization request to device > authorization endpoint. > > I suspect that it's largely an oversight because > public clients are really the conical use-case for the > device flow and no authentication is needed or > possible in that case. There are, however, likely to > be cases where a client with credentials will do the > device flow and it would be good for the AS to be able > to properly authenticate such clients before setting > up and saving the state for the transaction. Having > normal client authentication at device authorization > endpoint also brings better consistency to client > identification/authentication for requests made > directly from client to AS. > > > [1] error responses from the device authorization > endpoint should probably also be defined > https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4 > > > > /CONFIDENTIALITY NOTICE: This email may contain > confidential and privileged material for the sole use of > the intended recipient(s). Any review, use, distribution > or disclosure by others is strictly prohibited...  If you > have received this communication in error, please notify > the sender immediately by e-mail and delete the message > and any file attachments from your computer. Thank > you./_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited..  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Identity Standards Architect Verizon Media Work: george.fletcher@oath.com Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --------------BB17FE73430CD844181DD091 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1

to using the same client authn method as for the /token endpoint

On 3/11/19 12:31 PM, Brian Campbell wrote:


On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan <panva.ip@gmail.com> wrote:
Strike that, it should maybe just use the registered auth method for the token endpoint?

Yeah, that's what I'd think would be the way to go.
 

If there's auth we should also make it clear that client_id should not be omitted from the request body and it must be the same as the one provided with client authentication.


Fair point.


 
S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:14, Filip Skokan <panva.ip@gmail.com> wrote:
If we're about to add client authentication for the device_authorization_endpoint, i'd say we should also register for device_authorization_endpoint_auth_method, device_authorization_endpoint_auth_signing_alg client metadata. Maybe define the default value to be "none" / not provided to be in line with the late draft implementations. Wdyt?

S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
I do realize it's very late in the process for this document but believe these omissions can be addressed in the document with only minor changes/additions and that it'd be better late than not at all..

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
Another omission[1] (maybe, I believe it is anyway) to the Device Flow is that client authentication isn't defined for the device authorization request to device authorization endpoint.

I suspect that it's largely an oversight because public clients are really the conical use-case for the device flow and no authentication is needed or possible in that case. There are, however, likely to be cases where a client with credentials will do the device flow and it would be good for the AS to be able to properly authenticate such clients before setting up and saving the state for the transaction. Having normal client authentication at device authorization endpoint also brings better consistency to client identification/authentication for requests made directly from client to AS.  


[1] error responses from the device authorization endpoint should probably also be defined https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


-- 
Identity Standards Architect
Verizon Media                     Work: george.fletcher@oath.com
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
--------------BB17FE73430CD844181DD091-- From nobody Mon Mar 11 10:29:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3786131193 for ; Mon, 11 Mar 2019 10:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jpFUqHg38Lg3 for ; Mon, 11 Mar 2019 10:29:18 -0700 (PDT) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0991311B8 for ; Mon, 11 Mar 2019 10:29:09 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id t206so4322003oib.3 for ; Mon, 11 Mar 2019 10:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xX2MxjkriSD3HhyQ7/Bku4deF0+05KNZGXe+XPJMn9g=; b=njKJs4fDBSZ3k5C/LIC04BWUeJK5CebgSXK5FaTXGZAWhfe7w3D1Stym9wn7K3l67S YQ/VvnPkjYD+2HxnqZJCvX7KyokZWnBqlKSs9CIJfF9W5C3CoKGb+tVTd8EDETHqfWLv sfP1mjBUEgWoJIvy4zDzOf9ssQ8JIHChHAYq0mDqP3Wp4B5kT5nrbhkOWGzu6NT/NcZ7 9YpOzsexNuKu/lDBCiCgMILtA4rhJ5OT3AGDjUnqQhFuWBcirKh5fn+y32B8l4fNU1B5 pjCwvrapOcct06D3AcE2+7PYJgAVspXgdwbnYFn6kUtqmLu0LudT5+c/Dc4BJgzxT4Vq V++Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xX2MxjkriSD3HhyQ7/Bku4deF0+05KNZGXe+XPJMn9g=; b=Ydy5LxoPeaDU6wydiUEBH2+9zcfxQa2puIyXnHhOUhmg1YQlhKszx17McjOYEG5FAo 8BNQ1OCqpwUixlKzvyAI6xvYl0KnqrGU1oCMPUavbuysHTZIXlnIeY0pQQTCRR4RBx7z iPuSHTHXhw3vuF+k9Q1hh+CcLq2qZp1HhBV4MgyXkJzLPaG00vamDmb643pmvyE6r0HU m3v61AgZbX/QiNNR8RitrF4vsKZMTINIFsR6pHcv+8vIIRNwR8R7t+lTW9YpSid4UeyR nxHkMp/WxoEyZB7E2tcP5siXHcO6YEvVmrdVFFL8y1vpRL7n9900HwR6VsKH9M9RySup jIHg== X-Gm-Message-State: APjAAAUdd/sZQ2xpjDjhsMSEpXExh0nTqpdKN4vPvw22s2Qz4PpVojl0 ttSfywFU+S4wPTnKNuqqqecSH3g/GRxARoYsGw== X-Google-Smtp-Source: APXvYqwfAuwDv6dcgreFnsJ0Jgt7MpBBw1w86mJDuogF7Y5+xdvZce/6vvAPSqWeUBkBgZ8zg8bBTbyhaxRDzu68LOU= X-Received: by 2002:aca:33d5:: with SMTP id z204mr99285oiz.61.1552325348592; Mon, 11 Mar 2019 10:29:08 -0700 (PDT) MIME-Version: 1.0 References: <6312173.9VWeF3DjuQ@papegaaij> In-Reply-To: From: Filip Skokan Date: Mon, 11 Mar 2019 18:28:57 +0100 Message-ID: To: Emond Papegaaij Cc: oauth Content-Type: multipart/alternative; boundary="000000000000fa92240583d4e819" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device flow error response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:29:27 -0000 --000000000000fa92240583d4e819 Content-Type: text/plain; charset="UTF-8" Hi Emond, the way i approached implementation of device flow into an OIDC server was to allow all already registered and handled parameters excluding the ones [1] that really don't make sense for the flow at the device authorization endpoint. What can be validated at the device authorization endpoint time is, everything else runs as part of the regular authorization pipeline for which i also construct the request based on the params saved together with the device code backend model. Everything else that depends on the actual device where authnz happens is processed as part of the web request following the user code submission. When errors occur that cannot be resolved with user interaction the error is assigned to the device code and returned to the device with the next poll. I did not exclude prompt:none, as the pipeline processing starts after the submission it's possible that no prompt will occur there, but i can see how it may be weird. Yes the result at the token endpoint will include an id token if the scope included `openid` as one would expect, just like it will include a refresh token if `offline_access` is present. `resource` specifically is available as per the resource indicator spec at device authorization as well as token endpoints. I guess this is very similar to what you're thinking. I don't think we need to (and can for that matter) enumerate all possible OAuth2.0 extensions in the specification. [1] web_message_uri, web_message_target, response_type, response_mode, state, redirect_uri S pozdravem, *Filip Skokan* On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij wrote: > Yes, that's how I implemented it as well. I return 'invalid_request' > when the client_id is missing entirely. > > Do you have any thoughts how this specification should work in > combination with other specs, such as OIDC? For example, the OIDC > Authentication Request specifies several additional parameters, some > of which may be applicable for the device flow as well. Can the device > flow be used to obtain an ID token? How should parameters like > 'max_age', 'id_token_hint' and 'claims' be processed? My plan was to > construct a pseudo-authentication/authorization request using the > parameters specified at the device authorization endpoint and apply > these parameters during the user interaction. Some parameters, such as > 'prompt=3Dnone', do not make much sense though. > > I think it may be a good idea to describe how this spec is supposed to > interoperate with other specifications, especially those that extend > the Authorization Endpoint. This definition can never be complete, as > new specs will be defined after this one, but it can at least try to > describe the general rules that apply. > > PS. Other specifications also define additional parameters that may be > useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and > 'include_granted_scopes' from OAuth 2.0 Incremental Authorization. > > Best regards, > Emond Papegaaij > Topicus KeyHub > > On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell > wrote: > > > > While probably not terribly important from an interoperability > perspective, I agree that does seem like an omission. > > > > I took a quick look at our implementation and bad requests to the device > authorization endpoint will indeed return what is a standard OAuth 2.0 > error response normally from the token endpoint with invalid_client or > invalid_scope error codes. And a little bit of poking at Google's device > authorization endpoint suggests it behaves similarly. I suspect it's pretty > typical. > > > > > > > > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij < > emond.papegaaij@gmail.com> wrote: > >> > >> Dear all, > >> > >> I'm working on an implementation of the OAuth 2.0 Device Flow for > Browserless > >> and Input Constrained Devices and noticed a possible omission in the > spec. > >> Section 3.2 describes the Device Authorization Response, but only the > success > >> response is specified, not the error response. I would have expected a > >> standard OAuth 2.0 error response, probably with the following error > codes: > >> invalid_request, invalid_client and invalid_scope. > >> > >> Best regards, > >> Emond Papegaaij > >> Topicus KeyHub > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000fa92240583d4e819 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Emond,

t= he way i approached implementation of device flow into an OIDC server was t= o allow all already registered and handled parameters excluding the ones [1= ] that really don't make sense for the flow at the device authorization= endpoint.

What can be validated at the device aut= horization endpoint time is, everything else runs as part of the regular au= thorization pipeline for which i also construct the request based on the pa= rams saved together with the device code backend model. Everything else tha= t depends on the actual device where authnz happens is processed as part of= the web request following the user code submission. When errors occur that= cannot be resolved with user interaction the error is assigned to the devi= ce code and returned to the device with the next poll. I did not exclude pr= ompt:none, as the pipeline processing starts after the submission it's = possible that no prompt will occur there, but i can see how it may be weird= . Yes the result at the token endpoint will include an id token if the scop= e included `openid` as one would expect, just like it will include a refres= h token if `offline_access` is present. `resource` specifically is availabl= e as per the resource indicator spec at device authorization as well as tok= en endpoints.

I guess this is very similar to what= you're thinking.

I don't think we need to= (and can for that matter) enumerate all possible OAuth2.0 extensions in th= e specification.

[1]=C2=A0web_message_uri, web_mes= sage_target, response_type, response_mode, state, redirect_uri

S pozdravem,
Filip Skokan

<= /div>
O= n Mon, 11 Mar 2019 at 15:02, Emond Papegaaij <emond.papegaaij@gmail.com> wrot= e:
Yes, that'= ;s how I implemented it as well. I return 'invalid_request'
when the client_id is missing entirely.

Do you have any thoughts how this specification should work in
combination with other specs, such as OIDC? For example, the OIDC
Authentication Request specifies several additional parameters, some
of which may be applicable for the device flow as well. Can the device
flow be used to obtain an ID token? How should parameters like
'max_age', 'id_token_hint' and 'claims' be processe= d? My plan was to
construct a pseudo-authentication/authorization request using the
parameters specified at the device authorization endpoint and apply
these parameters during the user interaction. Some parameters, such as
'prompt=3D3Dnone', do not make much sense though.

I think it may be a good idea to describe how this spec is supposed to
interoperate with other specifications, especially those that extend
the Authorization Endpoint. This definition can never be complete, as
new specs will be defined after this one, but it can at least try to
describe the general rules that apply.

PS. Other specifications also define additional parameters that may be
useful, such as: 'resource' from Resource Indicators for OAuth 2.0 = and
'include_granted_scopes' from OAuth 2.0 Incremental Authorization.<= br>
Best regards,
Emond Papegaaij
Topicus KeyHub

On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell
<bcampbe= ll@pingidentity.com> wrote:
>
> While probably not terribly important from an interoperability perspec= tive, I agree that does seem like an omission.
>
> I took a quick look at our implementation and bad requests to the devi= ce authorization endpoint will indeed return what is a standard OAuth 2.0 e= rror response normally from the token endpoint with invalid_client or inval= id_scope error codes. And a little bit of poking at Google's device aut= horization endpoint suggests it behaves similarly. I suspect it's prett= y typical.
>
>
>
> On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij <emond.papegaaij@gmail.com&g= t; wrote:
>>
>> Dear all,
>>
>> I'm working on an implementation of the OAuth 2.0 Device Flow = for Browserless
>> and Input Constrained Devices and noticed a possible omission in t= he spec.
>> Section 3.2 describes the Device Authorization Response, but only = the success
>> response is specified, not the error response. I would have expect= ed a
>> standard OAuth 2.0 error response, probably with the following err= or codes:
>> invalid_request, invalid_client and invalid_scope.
>>
>> Best regards,
>> Emond Papegaaij
>> Topicus KeyHub
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your = computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000fa92240583d4e819-- From nobody Mon Mar 11 10:30:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465E7131168 for ; Mon, 11 Mar 2019 10:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 MWCUf5Yxoj3z for ; Mon, 11 Mar 2019 10:30:22 -0700 (PDT) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 7406E1311CA for ; Mon, 11 Mar 2019 10:30:20 -0700 (PDT) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2BHTP63173463; Mon, 11 Mar 2019 17:30:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=Yc7RS0U6xvsd080aeCuLXk9+/XxPNM0k7uCvP8agUD4=; b=IZNaMIO55nldPlB5zpZB1ay6ZOgbgPnLNd4IFOd3WoeswIgpv+BzpFvKEfSMRAaMGN1+ vrlHPLNH0WUHWPluEmts6IhEUWJu7ksiV3o8SlEzS3E8cNjQPLQQg56VFW6Z8WGbxNsu Z0m21ATCGXj68c5luF0oZq3D/Ll/Ryk/G7UzHNVQ9CEdKVbqXqz146fZ+b8L8u9yUZgP 6ZdZU8W3bQaouBY+k4e5aWKpseBJR2ZHUsr0/CjuvdWZ1u3nbSqFDF2g7z0+kN4cXOgb XNDBcYRmR6O5QxxNnEpaC1RwmIbmYd7m8Jg2zaHpPKdCofsNhjTHLvnuL9AIh7mYyPHo Yg== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2r430egcmk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Mar 2019 17:30:16 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x2BHUADs021959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Mar 2019 17:30:10 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x2BHUAfs009395; Mon, 11 Mar 2019 17:30:10 GMT Received: from [192.168.1.22] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Mar 2019 17:30:09 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-E27793B1-50E6-481D-A74B-E6A908C3628F Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (16D57) In-Reply-To: <7c605f52-ff7f-49cd-0a4e-af3aa15663be@aol.com> Date: Mon, 11 Mar 2019 10:30:08 -0700 Cc: Brian Campbell , Filip Skokan , oauth Content-Transfer-Encoding: 7bit Message-Id: <710ACBA5-C43D-4396-A3AE-9D7156204E3E@oracle.com> References: <7c605f52-ff7f-49cd-0a4e-af3aa15663be@aol.com> To: George Fletcher X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9192 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110125 Archived-At: Subject: Re: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:30:30 -0000 --Apple-Mail-E27793B1-50E6-481D-A74B-E6A908C3628F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 to using same authentication requirements as for token endpoint.=20 Phil > On Mar 11, 2019, at 10:27 AM, George Fletcher wrote: >=20 > +1 >=20 > to using the same client authn method as for the /token endpoint >=20 >> On 3/11/19 12:31 PM, Brian Campbell wrote: >>=20 >>=20 >>> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan wrote= : >>> Strike that, it should maybe just use the registered auth method for the= token endpoint? >>=20 >> Yeah, that's what I'd think would be the way to go.=20 >> =20 >>>=20 >>> If there's auth we should also make it clear that client_id should not b= e omitted from the request body and it must be the same as the one provided w= ith client authentication. >>>=20 >>=20 >> Fair point.=20 >>=20 >>=20 >> =20 >>> S pozdravem, >>> Filip Skokan >>>=20 >>>=20 >>>> On Mon, 11 Mar 2019 at 17:14, Filip Skokan wrote: >>>> If we're about to add client authentication for the device_authorizatio= n_endpoint, i'd say we should also register for device_authorization_endpoin= t_auth_method, device_authorization_endpoint_auth_signing_alg client metadat= a. Maybe define the default value to be "none" / not provided to be in line w= ith the late draft implementations. Wdyt? >>>>=20 >>>> S pozdravem, >>>> Filip Skokan >>>>=20 >>>>=20 >>>>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell wrote: >>>>> I do realize it's very late in the process for this document but belie= ve these omissions can be addressed in the document with only minor changes/= additions and that it'd be better late than not at all..=20 >>>>>=20 >>>>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell wrote: >>>>>> Another omission[1] (maybe, I believe it is anyway) to the Device Flo= w is that client authentication isn't defined for the device authorization r= equest to device authorization endpo= int.=20 >>>>>>=20 >>>>>> I suspect that it's largely an oversight because public clients are r= eally the conical use-case for the device flow and no authentication is need= ed or possible in that case. There are, however, likely to be cases where a c= lient with credentials will do the device flow and it would be good for the A= S to be able to properly authenticate such clients before setting up and sav= ing the state for the transaction. Having normal client authentication at de= vice authorization endpoint also brings better consistency to client identif= ication/authentication for requests made directly from client to AS. =20 >>>>>>=20 >>>>>>=20 >>>>>> [1] error responses from the device authorization endpoint should pro= bably also be defined https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdN= QPiLh0xVXe39933k4=20 >>>>>>=20 >>>>>=20 >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, use= , distribution or disclosure by others is strictly prohibited... If you hav= e received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your compute= r. Thank you._______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you.=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > --=20 > Identity Standards Architect > Verizon Media Work: george.fletcher@oath.com > Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch > Office: +1-703-265-2544 Photos: http://georgefletcher.photograph= y > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&= r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DT9FBaSmKjH9DP1tZy7yS2PWN= PsktsU0izt30MhOcMpw&s=3DA-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e=3D --Apple-Mail-E27793B1-50E6-481D-A74B-E6A908C3628F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit +1 to using same authentication requirements as for token endpoint. 

Phil

On Mar 11, 2019, at 10:27 AM, George Fletcher <gffletch=40aol.com@dmarc.ietf.org> wrote:

+1

to using the same client authn method as for the /token endpoint

On 3/11/19 12:31 PM, Brian Campbell wrote:


On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan <panva.ip@gmail.com> wrote:
Strike that, it should maybe just use the registered auth method for the token endpoint?

Yeah, that's what I'd think would be the way to go.
 

If there's auth we should also make it clear that client_id should not be omitted from the request body and it must be the same as the one provided with client authentication.


Fair point.


 
S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:14, Filip Skokan <panva.ip@gmail.com> wrote:
If we're about to add client authentication for the device_authorization_endpoint, i'd say we should also register for device_authorization_endpoint_auth_method, device_authorization_endpoint_auth_signing_alg client metadata. Maybe define the default value to be "none" / not provided to be in line with the late draft implementations. Wdyt?

S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
I do realize it's very late in the process for this document but believe these omissions can be addressed in the document with only minor changes/additions and that it'd be better late than not at all..

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <bcampbell@pingidentity.com> wrote:
Another omission[1] (maybe, I believe it is anyway) to the Device Flow is that client authentication isn't defined for the device authorization request to device authorization endpoint.

I suspect that it's largely an oversight because public clients are really the conical use-case for the device flow and no authentication is needed or possible in that case. There are, however, likely to be cases where a client with credentials will do the device flow and it would be good for the AS to be able to properly authenticate such clients before setting up and saving the state for the transaction. Having normal client authentication at device authorization endpoint also brings better consistency to client identification/authentication for requests made directly from client to AS.  


[1] error responses from the device authorization endpoint should probably also be defined https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


-- 
Identity Standards Architect
Verizon Media                     Work: george.fletcher@oath.com
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
--Apple-Mail-E27793B1-50E6-481D-A74B-E6A908C3628F-- From nobody Mon Mar 11 10:41:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E541311E2 for ; Mon, 11 Mar 2019 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yoBfC4Ug7tl3 for ; Mon, 11 Mar 2019 10:41:28 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FA91311B8 for ; Mon, 11 Mar 2019 10:41:27 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id z124so61424itc.2 for ; Mon, 11 Mar 2019 10:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HfP49oIwxZ9LhK9qK1jk8fV/yJDqEcpirkf/hVAW1Qk=; b=jTUOh7RFIKqj4lSTCWOPOFK+bux4Nd+CLCKvwmD7wtOld8GX3VC1LgMete85Fzkv1N 4N72qgdOb6BoIM0JasjhE7KrdO4BzBifacQKbLCGIhN4ExYZTw16W5iHJVKeNynlEHDZ l25A1CWHGv+S8lRZHupaRbf4fntJt98er3Q0ZqfuIVK7nTsm8pWGwo1taADBJyks9n01 KSVg9iNGdXlQehOg61s1aZisTbncnXnTZwRAYVsfYGEtM0DijG/2+5LanLKa40Y64aJ7 trOOam7yp7fnVQjNOhNL/MM/YFeCueZzAnvg4a4cvvqGHbfciN57YM1LsmuR7i9ibrX5 ZoGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HfP49oIwxZ9LhK9qK1jk8fV/yJDqEcpirkf/hVAW1Qk=; b=hWSLHRifrTO0QYD1D7Hr+b8hCLpvyXqIhHMnidsBV3ufbpC6D9BZ48JVNxijcqwWs4 X7l8lmkfX8Imy+Cu1R5mFIOaA/yKO2vD5IuMORxfES1BM9tMPNkYWg6jVsGIKbfjSPEK 6U94wcCQgeggEoBVq2PoGrVJ074FL1vDlBFXLKTzfJIYsmEvFI9EBN0kf0OjqBTLeq3Y K961N+ne0jbzoNefxXh/PCfccXQ1keyE9B2JT1sQmuITflRCrxfTFzi8c4BTe2WpblDH +VsnYzmCsAcTJiNq4HXl/jO5g919KEOpU4DyoyP0WJ5x5AiiehgvcT88Hv94ihcELGsm I26A== X-Gm-Message-State: APjAAAVt88rW1jombEHSaiF1KyKUFD1Sk2rRA8F2PaGJuqyrEOAIlMmo 4U4udxx+/WXIys91A95S+/ecOUMZQLDMDsQW7C4DmibV X-Google-Smtp-Source: APXvYqy/hTFKeB8IF78zx+mteaoxrW7ouI+IKfl+vK0PpWK1l1fcHeDQcOUCe9KhysTXFGyrQwjIwU7FwxAXxQWqXBc= X-Received: by 2002:a02:c908:: with SMTP id t8mr10474994jao.59.1552326086933; Mon, 11 Mar 2019 10:41:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?7J207LKc7Jqx?= Date: Tue, 12 Mar 2019 02:41:15 +0900 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000fcc0bf0583d51401" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 125, Issue 10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:41:31 -0000 --000000000000fcc0bf0583d51401 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello.You need not send email. Thank you. 2019=EB=85=84 3=EC=9B=94 12=EC=9D=BC (=ED=99=94) =EC=98=A4=EC=A0=84 2:31, <= oauth-request@ietf.org>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: OAuth 2.0 Device flow error response (Filip Skokan) > 2. Re: Client authentication in the Device Authorization Request > (Phil Hunt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 11 Mar 2019 18:28:57 +0100 > From: Filip Skokan > To: Emond Papegaaij > Cc: oauth > Subject: Re: [OAUTH-WG] OAuth 2.0 Device flow error response > Message-ID: > EO2MXb+GTEkQcN3+g@mail.gmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > Hi Emond, > > the way i approached implementation of device flow into an OIDC server wa= s > to allow all already registered and handled parameters excluding the ones > [1] that really don't make sense for the flow at the device authorization > endpoint. > > What can be validated at the device authorization endpoint time is, > everything else runs as part of the regular authorization pipeline for > which i also construct the request based on the params saved together wit= h > the device code backend model. Everything else that depends on the actual > device where authnz happens is processed as part of the web request > following the user code submission. When errors occur that cannot be > resolved with user interaction the error is assigned to the device code a= nd > returned to the device with the next poll. I did not exclude prompt:none, > as the pipeline processing starts after the submission it's possible that > no prompt will occur there, but i can see how it may be weird. Yes the > result at the token endpoint will include an id token if the scope includ= ed > `openid` as one would expect, just like it will include a refresh token i= f > `offline_access` is present. `resource` specifically is available as per > the resource indicator spec at device authorization as well as token > endpoints. > > I guess this is very similar to what you're thinking. > > I don't think we need to (and can for that matter) enumerate all possible > OAuth2.0 extensions in the specification. > > [1] web_message_uri, web_message_target, response_type, response_mode, > state, redirect_uri > > S pozdravem, > *Filip Skokan* > > > On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij > wrote: > > > Yes, that's how I implemented it as well. I return 'invalid_request' > > when the client_id is missing entirely. > > > > Do you have any thoughts how this specification should work in > > combination with other specs, such as OIDC? For example, the OIDC > > Authentication Request specifies several additional parameters, some > > of which may be applicable for the device flow as well. Can the device > > flow be used to obtain an ID token? How should parameters like > > 'max_age', 'id_token_hint' and 'claims' be processed? My plan was to > > construct a pseudo-authentication/authorization request using the > > parameters specified at the device authorization endpoint and apply > > these parameters during the user interaction. Some parameters, such as > > 'prompt=3D3Dnone', do not make much sense though. > > > > I think it may be a good idea to describe how this spec is supposed to > > interoperate with other specifications, especially those that extend > > the Authorization Endpoint. This definition can never be complete, as > > new specs will be defined after this one, but it can at least try to > > describe the general rules that apply. > > > > PS. Other specifications also define additional parameters that may be > > useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and > > 'include_granted_scopes' from OAuth 2.0 Incremental Authorization. > > > > Best regards, > > Emond Papegaaij > > Topicus KeyHub > > > > On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell > > wrote: > > > > > > While probably not terribly important from an interoperability > > perspective, I agree that does seem like an omission. > > > > > > I took a quick look at our implementation and bad requests to the > device > > authorization endpoint will indeed return what is a standard OAuth 2.0 > > error response normally from the token endpoint with invalid_client or > > invalid_scope error codes. And a little bit of poking at Google's devic= e > > authorization endpoint suggests it behaves similarly. I suspect it's > pretty > > typical. > > > > > > > > > > > > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij < > > emond.papegaaij@gmail.com> wrote: > > >> > > >> Dear all, > > >> > > >> I'm working on an implementation of the OAuth 2.0 Device Flow for > > Browserless > > >> and Input Constrained Devices and noticed a possible omission in the > > spec. > > >> Section 3.2 describes the Device Authorization Response, but only th= e > > success > > >> response is specified, not the error response. I would have expected= a > > >> standard OAuth 2.0 error response, probably with the following error > > codes: > > >> invalid_request, invalid_client and invalid_scope. > > >> > > >> Best regards, > > >> Emond Papegaaij > > >> Topicus KeyHub > > >> > > >> > > >> _______________________________________________ > > >> OAuth mailing list > > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged material for the sole use of the intended recipient(s). Any > > review, use, distribution or disclosure by others is strictly prohibite= d. > > If you have received this communication in error, please notify the > sender > > immediately by e-mail and delete the message and any file attachments > from > > your computer. Thank you. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190311/12994= b9b/attachment.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 11 Mar 2019 10:30:08 -0700 > From: Phil Hunt > To: George Fletcher > Cc: Brian Campbell , > Filip Skokan , oauth > Subject: Re: [OAUTH-WG] Client authentication in the Device > Authorization Request > Message-ID: <710ACBA5-C43D-4396-A3AE-9D7156204E3E@oracle.com> > Content-Type: text/plain; charset=3D"us-ascii" > > +1 to using same authentication requirements as for token endpoint. > > Phil > > > On Mar 11, 2019, at 10:27 AM, George Fletcher 40aol.com@dmarc.ietf.org> wrote: > > > > +1 > > > > to using the same client authn method as for the /token endpoint > > > >> On 3/11/19 12:31 PM, Brian Campbell wrote: > >> > >> > >>> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan > wrote: > >>> Strike that, it should maybe just use the registered auth method for > the token endpoint? > >> > >> Yeah, that's what I'd think would be the way to go. > >> > >>> > >>> If there's auth we should also make it clear that client_id should no= t > be omitted from the request body and it must be the same as the one > provided with client authentication. > >>> > >> > >> Fair point. > >> > >> > >> > >>> S pozdravem, > >>> Filip Skokan > >>> > >>> > >>>> On Mon, 11 Mar 2019 at 17:14, Filip Skokan > wrote: > >>>> If we're about to add client authentication for the > device_authorization_endpoint, i'd say we should also register for > device_authorization_endpoint_auth_method, > device_authorization_endpoint_auth_signing_alg client metadata. Maybe > define the default value to be "none" / not provided to be in line with t= he > late draft implementations. Wdyt? > >>>> > >>>> S pozdravem, > >>>> Filip Skokan > >>>> > >>>> > >>>>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >>>>> I do realize it's very late in the process for this document but > believe these omissions can be addressed in the document with only minor > changes/additions and that it'd be better late than not at all.. > >>>>> > >>>>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell < > bcampbell@pingidentity.com> wrote: > >>>>>> Another omission[1] (maybe, I believe it is anyway) to the Device > Flow is that client authentication isn't defined for the device > authorization request to device authorization > endpoint. > >>>>>> > >>>>>> I suspect that it's largely an oversight because public clients ar= e > really the conical use-case for the device flow and no authentication is > needed or possible in that case. There are, however, likely to be cases > where a client with credentials will do the device flow and it would be > good for the AS to be able to properly authenticate such clients before > setting up and saving the state for the transaction. Having normal client > authentication at device authorization endpoint also brings better > consistency to client identification/authentication for requests made > directly from client to AS. > >>>>>> > >>>>>> > >>>>>> [1] error responses from the device authorization endpoint should > probably also be defined > https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4 > >>>>>> > >>>>> > >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited... If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any fi= le > attachments from your computer. Thank > you._______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Identity Standards Architect > > Verizon Media Work: george.fletcher@oath.com > > Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch > > Office: +1-703-265-2544 Photos: > http://georgefletcher.photography > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_Jn= E&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DT9FBaSmKjH9DP1tZy7yS2= PWNPsktsU0izt30MhOcMpw&s=3DA-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e=3D > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190311/4250b= fe2/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 125, Issue 10 > ************************************** > --000000000000fcc0bf0583d51401 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.You need not send email.
Thank you= .

2019=EB=85=84 3=EC=9B=94 12=EC=9D=BC (=ED=99=94) =EC=98=A4=EC=A0=84 = 2:31, <oauth-request@ietf.org= >=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
Send OAuth mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: OAuth 2.0 Device flow error response (Filip Skokan)
=C2=A0 =C2=A02. Re: Client authentication in the Device Authorization Reque= st
=C2=A0 =C2=A0 =C2=A0 (Phil Hunt)


----------------------------------------------------------------------

Message: 1
Date: Mon, 11 Mar 2019 18:28:57 +0100
From: Filip Skokan <panva.ip@gmail.com>
To: Emond Papegaaij <emond.papegaaij@gmail.com>
Cc: oauth <OAuth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Device flow error response
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CALAqi_9dDuZxuh0gdLaHuFq_UAQ2fTjq=3DEO2MXb+GTEkQcN3+g@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Hi Emond,

the way i approached implementation of device flow into an OIDC server was<= br> to allow all already registered and handled parameters excluding the ones [1] that really don't make sense for the flow at the device authorizati= on
endpoint.

What can be validated at the device authorization endpoint time is,
everything else runs as part of the regular authorization pipeline for
which i also construct the request based on the params saved together with<= br> the device code backend model. Everything else that depends on the actual device where authnz happens is processed as part of the web request
following the user code submission. When errors occur that cannot be
resolved with user interaction the error is assigned to the device code and=
returned to the device with the next poll. I did not exclude prompt:none, as the pipeline processing starts after the submission it's possible th= at
no prompt will occur there, but i can see how it may be weird. Yes the
result at the token endpoint will include an id token if the scope included=
`openid` as one would expect, just like it will include a refresh token if<= br> `offline_access` is present. `resource` specifically is available as per the resource indicator spec at device authorization as well as token
endpoints.

I guess this is very similar to what you're thinking.

I don't think we need to (and can for that matter) enumerate all possib= le
OAuth2.0 extensions in the specification.

[1] web_message_uri, web_message_target, response_type, response_mode,
state, redirect_uri

S pozdravem,
*Filip Skokan*


On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij <emond.papegaaij@gm= ail.com>
wrote:

> Yes, that's how I implemented it as well. I return 'invalid_re= quest'
> when the client_id is missing entirely.
>
> Do you have any thoughts how this specification should work in
> combination with other specs, such as OIDC? For example, the OIDC
> Authentication Request specifies several additional parameters, some > of which may be applicable for the device flow as well. Can the device=
> flow be used to obtain an ID token? How should parameters like
> 'max_age', 'id_token_hint' and 'claims' be pro= cessed? My plan was to
> construct a pseudo-authentication/authorization request using the
> parameters specified at the device authorization endpoint and apply > these parameters during the user interaction. Some parameters, such as=
> 'prompt=3D3Dnone', do not make much sense though.
>
> I think it may be a good idea to describe how this spec is supposed to=
> interoperate with other specifications, especially those that extend > the Authorization Endpoint. This definition can never be complete, as<= br> > new specs will be defined after this one, but it can at least try to > describe the general rules that apply.
>
> PS. Other specifications also define additional parameters that may be=
> useful, such as: 'resource' from Resource Indicators for OAuth= 2.0 and
> 'include_granted_scopes' from OAuth 2.0 Incremental Authorizat= ion.
>
> Best regards,
> Emond Papegaaij
> Topicus KeyHub
>
> On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell
> <bcampbell@pingidentity.com> wrote:
> >
> > While probably not terribly important from an interoperability > perspective, I agree that does seem like an omission.
> >
> > I took a quick look at our implementation and bad requests to the= device
> authorization endpoint will indeed return what is a standard OAuth 2.0=
> error response normally from the token endpoint with invalid_client or=
> invalid_scope error codes. And a little bit of poking at Google's = device
> authorization endpoint suggests it behaves similarly. I suspect it'= ;s pretty
> typical.
> >
> >
> >
> > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij <
> emond.papegaaij@gmail.com> wrote:
> >>
> >> Dear all,
> >>
> >> I'm working on an implementation of the OAuth 2.0 Device = Flow for
> Browserless
> >> and Input Constrained Devices and noticed a possible omission= in the
> spec.
> >> Section 3.2 describes the Device Authorization Response, but = only the
> success
> >> response is specified, not the error response. I would have e= xpected a
> >> standard OAuth 2.0 error response, probably with the followin= g error
> codes:
> >> invalid_request, invalid_client and invalid_scope.
> >>
> >> Best regards,
> >> Emond Papegaaij
> >> Topicus KeyHub
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/l= istinfo/oauth
> >
> >
> > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any=
> review, use, distribution or disclosure by others is strictly prohibit= ed.
> If you have received this communication in error, please notify the se= nder
> immediately by e-mail and delete the message and any file attachments = from
> your computer. Thank you.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oau= th
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2019= 0311/12994b9b/attachment.html>

------------------------------

Message: 2
Date: Mon, 11 Mar 2019 10:30:08 -0700
From: Phil Hunt <phil.hunt@oracle.com>
To: George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> Cc: Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.= ietf.org>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filip Skokan <panva.ip@gmail.com>, oa= uth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Client authentication in the Device
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authorization Request
Message-ID: <710ACBA5-C43D-4396-A3AE-9D7156= 204E3E@oracle.com>
Content-Type: text/plain; charset=3D"us-ascii"

+1 to using same authentication requirements as for token endpoint.

Phil

> On Mar 11, 2019, at 10:27 AM, George Fletcher <gffletch=3D4= 0aol.com@dmarc.ietf.org> wrote:
>
> +1
>
> to using the same client authn method as for the /token endpoint
>
>> On 3/11/19 12:31 PM, Brian Campbell wrote:
>>
>>
>>> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan <panva.ip@gma= il.com> wrote:
>>> Strike that, it should maybe just use the registered auth meth= od for the token endpoint?
>>
>> Yeah, that's what I'd think would be the way to go.
>>=C2=A0
>>>
>>> If there's auth we should also make it clear that client_i= d should not be omitted from the request body and it must be the same as th= e one provided with client authentication.
>>>
>>
>> Fair point.
>>
>>
>>=C2=A0
>>> S pozdravem,
>>> Filip Skokan
>>>
>>>
>>>> On Mon, 11 Mar 2019 at 17:14, Filip Skokan <panva.ip@gm= ail.com> wrote:
>>>> If we're about to add client authentication for the de= vice_authorization_endpoint, i'd say we should also register for device= _authorization_endpoint_auth_method, device_authorization_endpoint_auth_sig= ning_alg client metadata. Maybe define the default value to be "none&q= uot; / not provided to be in line with the late draft implementations. Wdyt= ?
>>>>
>>>> S pozdravem,
>>>> Filip Skokan
>>>>
>>>>
>>>>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcamp= bell=3D40pingidentity.com@dmarc.ietf.org> wrote:
>>>>> I do realize it's very late in the process for thi= s document but believe these omissions can be addressed in the document wit= h only minor changes/additions and that it'd be better late than not at= all..
>>>>>
>>>>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell &l= t;bcampbell@pingidentity.com> wrote:
>>>>>> Another omission[1] (maybe, I believe it is anyway= ) to the Device Flow is that client authentication isn't defined for th= e device authorization request to device authorization=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0endpoint.
>>>>>>
>>>>>> I suspect that it's largely an oversight becau= se public clients are really the conical use-case for the device flow and n= o authentication is needed or possible in that case. There are, however, li= kely to be cases where a client with credentials will do the device flow an= d it would be good for the AS to be able to properly authenticate such clie= nts before setting up and saving the state for the transaction. Having norm= al client authentication at device authorization endpoint also brings bette= r consistency to client identification/authentication for requests made dir= ectly from client to AS.=C2=A0
>>>>>>
>>>>>>
>>>>>> [1] error responses from the device authorization = endpoint should probably also be defined https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1ms= dNQPiLh0xVXe39933k4
>>>>>>
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= . Any review, use, distribution or disclosure by others is strictly prohibi= ted...=C2=A0 If you have received this communication in error, please notif= y the sender immediately by e-mail and delete the message and any file atta= chments from your computer. Thank you._____________________________________= __________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mail= man/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/list= info/oauth
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review= , use, distribution or disclosure by others is strictly prohibited..=C2=A0 = If you have received this communication in error, please notify the sender = immediately by e-mail and delete the message and any file attachments from = your computer. Thank you.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo= /oauth
>
> --
> Identity Standards Architect
> Verizon Media=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Work: george.fletcher@oath.com
> Mobile: +1-703-462-3494=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Twitte= r: http://twitter.com/gffletch
> Office: +1-703-265-2544=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Photos= : http://georgefletcher.photography
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f.org_mailman_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh= 8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&am= p;m=3DT9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw&s=3DA-TWytTVW596UG0zc= 6oz1rozU_auZJ0bIPSGqtXnTGA&e=3D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2019= 0311/4250bfe2/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 125, Issue 10
**************************************
--000000000000fcc0bf0583d51401-- From nobody Mon Mar 11 11:10:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A596E127817 for ; Mon, 11 Mar 2019 11:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VwsqtXCoLBku for ; Mon, 11 Mar 2019 11:10:30 -0700 (PDT) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF250124BF6 for ; Mon, 11 Mar 2019 11:10:29 -0700 (PDT) Received: by mail-it1-x12b.google.com with SMTP id l139so111342ita.5 for ; Mon, 11 Mar 2019 11:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MaHRKFzJcxbDCkE/hEDzAOe+H0vYQHJvTFThU6lYOBI=; b=ehGJkBYQ4ZSF7gLVqNKeu2lFeDol3WhhY3S0i19YSqngP5dJ5u8gvbhateY8gbk6mr H+7YC5QRpfwG6SfuNPsKi/aaq2B8eLlZfCi20HR18wVxYi9KSacfoCeCnrNKKTADT3WR dCKH5i9MjRk5nvCdIaypOmG07qkpCluwA1yZtsYE3BSyMpPYLgntc79p0GUSiNu8lYRY TzSbJcPAWPBh8KLSmvATIO5JraBI24V5MlXEOjt/ZzG47Xur9zn5OU78ThzzHuAZ3HZF bAEAp/BSgwKtv/bUCdauTCXQ4NgamYdjliuNmmhr2r5DB+J0IPrLk3TXeVP+W/K1H9xi sHxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MaHRKFzJcxbDCkE/hEDzAOe+H0vYQHJvTFThU6lYOBI=; b=ePxgRQfyK6yZ6A4wUj/o+CGqCHW3Xt4buc6vS4mpbuUOpoM+og3moNf1wOVHMo8BVw ERfB+y8uJcj9YjiodcJqsAi64REbN0596dY8fitmC6rINZ2iH2ts0X+Zun4XRko2RvyK 6VDBPdTRnuc8P5KQK7yyR18wTCKJULuFx55RkJkKy+UO4z5KLI2feCLD5qWoU33fA2yW RloavguBTEJauc090+Ya8vgsqWaHwJAg5W7MuW9WFW1Xp5H5e+Mi8R/DH9JspalbosNx nLtGWokfZup9rYCDprjtLASF24vGa0s6MH5t56I7lIEkZsPjof/yLpoG6CIkbvIXQM6x HMpw== X-Gm-Message-State: APjAAAUHDlItkuUacIeLmdzPunGRGqv/0NhNeHMzF+UmapKEnR9Z6wdO 9cpAUf1CkNXTGDYgUV5nSBVirHWGU2vGIP0RBFySEAjaMb8= X-Google-Smtp-Source: APXvYqwi7PYqsNA4LFL9T7yjmMy93a26dc8jJ0zQ3e35Otp0a9Fo+AFLdr+IvS9jwdokT+wEUfvWI27w/cVdIdoDs7I= X-Received: by 2002:a05:660c:a13:: with SMTP id e19mr14558itk.165.1552327828740; Mon, 11 Mar 2019 11:10:28 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 11 Mar 2019 14:10:17 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000ce9d970583d57cef" Archived-At: Subject: [OAUTH-WG] Nested JWT draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 18:10:32 -0000 --000000000000ce9d970583d57cef Content-Type: text/plain; charset="UTF-8" Hi, I have just submitted the following short draft with some *initial thoughts *on extending the Nested JWT concept defined in the RFC7519, to allow the enclosing JWT to have its own Claims Set. https://www.ietf.org/id/draft-yusef-oauth-nested-jwt-00.txt I would appreciate any reviews and comments about this draft. Regards, Rifaat --000000000000ce9d970583d57cef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--000000000000ce9d970583d57cef-- From nobody Mon Mar 11 12:18:38 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF64127971 for ; Mon, 11 Mar 2019 12:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.511 X-Spam-Level: X-Spam-Status: No, score=-15.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 beUNpsFA7wAG for ; Mon, 11 Mar 2019 12:18:34 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DFC4124C04 for ; Mon, 11 Mar 2019 12:18:34 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id z124so485646itc.2 for ; Mon, 11 Mar 2019 12:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=igdiUlIMSwcCAIe66b2iuw/XrX87mxVTIvczdgYNqNI=; b=u4+EYEj0GPPlYJcITIihCuqfQ3CtubxDdIS8i3/OnxFEatR1eZ2IKenm7R7qNYMGVG tcQFG1JCQBvlwiV8gGiig3shk64NDXe+HKZWhDfoPztF1HK3qE3ER11nA/kBTxNwd68h +bEYcMcUSAsUAJhwmvaaE8P06s5QsS7Z4tZG3TljPOxNZ1yJ5av8fanWFDix2ItfYmTB Abxh8S0qvydJ1BSw5NPSTQIkCWJcxPXA/m5vcckcPvGoEfO7a9Vki0iKwRf8bdlXguqD XXDbMbZZ7R+iD4Mey63QozzaCr197zT9fntgfpLLMquQpBemZZ6QgSCVi29ypPne99VW SFKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=igdiUlIMSwcCAIe66b2iuw/XrX87mxVTIvczdgYNqNI=; b=h8lo88Ev64PqGSWcwVs9u16+1RqjMkFTGR8KrgvnwN4oeaf+jIhmSa5EQvyCaxTFMb sgirstZVT019uZCNLfUZ0BGklEL89kIUGWFpOVeWiHX8V3iNM9YfajYCcv8cRZ+hxQKj 0KPtIdY/WyUZPQHDOIj0vKPLVzJOwiK9CJjWb4ovzdYuAU97Gjx1QsE0MD7BHNqAMgTi xYhbaHTTwfHVZEg6NMVOtVmGr4vv+998R79WuI0ecyZ97ShsbtJrxjesgxAxEZUwrH2l duWpVOAAzFQ4hLy/+oFxM89W0sTj/YJJ7cNIn8TGG04m1c5MrPLDg4ajGhqFRnKVdwjD baHA== X-Gm-Message-State: APjAAAWoWV26PUhcrysm6LclIgBWGYYTLRU7M+eVpMJ3kniqpPzGqApa IJZEIqG7hlbysRspDRn3POQIHDSExcA8oHVAPIExCw== X-Google-Smtp-Source: APXvYqyueqov5BVn0VOx6qxu5KxRklX10Hn1KrEcqnuwjVj3GYdq0WXHgtVbChtappjqvDXUDQd0OTP2z/bRazzRC4s= X-Received: by 2002:a24:5f52:: with SMTP id r79mr214235itb.125.1552331913146; Mon, 11 Mar 2019 12:18:33 -0700 (PDT) MIME-Version: 1.0 References: <7c605f52-ff7f-49cd-0a4e-af3aa15663be@aol.com> <710ACBA5-C43D-4396-A3AE-9D7156204E3E@oracle.com> In-Reply-To: <710ACBA5-C43D-4396-A3AE-9D7156204E3E@oracle.com> From: William Denniss Date: Mon, 11 Mar 2019 12:18:21 -0700 Message-ID: To: Phil Hunt Cc: George Fletcher , Brian Campbell , oauth Content-Type: multipart/alternative; boundary="0000000000004214490583d670d2" Archived-At: Subject: Re: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 19:18:37 -0000 --0000000000004214490583d670d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Brian for raising this. Yes, the expectation I believe is to follow the same approach as the token endpoint. As the spec is primarily for public clients, that's what we documented explicitly but it's worth calling out. Would the following text suffice in order to "inherit" the client authentication requirements of the token endpoint do you think? "The client authentication requirements of Section 3.2.1 of RFC6749 apply to requests on this endpoint." Then there's the matter of the REQUIRED "client_id" parameter. Perhaps we could say "REQUIRED, unless the client authenticates per Section 2.3 of RFC6749" On Mon, Mar 11, 2019 at 10:30 AM Phil Hunt wrote: > +1 to using same authentication requirements as for token endpoint. > > Phil > > On Mar 11, 2019, at 10:27 AM, George Fletcher < > gffletch=3D40aol.com@dmarc.ietf.org> wrote: > > +1 > > to using the same client authn method as for the /token endpoint > > On 3/11/19 12:31 PM, Brian Campbell wrote: > > > > On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan wrote: > >> Strike that, it should maybe just use the registered auth method for the >> token endpoint? >> > > Yeah, that's what I'd think would be the way to go. > > >> >> If there's auth we should also make it clear that client_id should not b= e >> omitted from the request body and it must be the same as the one provide= d >> with client authentication. >> >> > Fair point. > > > > >> S pozdravem, >> *Filip Skokan* >> >> >> On Mon, 11 Mar 2019 at 17:14, Filip Skokan wrote: >> >>> If we're about to add client authentication for the >>> device_authorization_endpoint, i'd say we should also register for >>> device_authorization_endpoint_auth_method, >>> device_authorization_endpoint_auth_signing_alg client metadata. Maybe >>> define the default value to be "none" / not provided to be in line with= the >>> late draft implementations. Wdyt? >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell >> 40pingidentity.com@dmarc.ietf.org> wrote: >>> >>>> I do realize it's very late in the process for this document but >>>> believe these omissions can be addressed in the document with only min= or >>>> changes/additions and that it'd be better late than not at all.. >>>> >>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> Another omission[1] (maybe, I believe it is anyway) to the Device Flo= w >>>>> is that client authentication isn't defined for the device authorizat= ion >>>>> request to device authorization endpoint. >>>>> >>>>> I suspect that it's largely an oversight because public clients are >>>>> really the conical use-case for the device flow and no authentication= is >>>>> needed or possible in that case. There are, however, likely to be cas= es >>>>> where a client with credentials will do the device flow and it would = be >>>>> good for the AS to be able to properly authenticate such clients befo= re >>>>> setting up and saving the state for the transaction. Having normal cl= ient >>>>> authentication at device authorization endpoint also brings better >>>>> consistency to client identification/authentication for requests made >>>>> directly from client to AS. >>>>> >>>>> >>>>> [1] error responses from the device authorization endpoint should >>>>> probably also be defined >>>>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933= k4 >>>>> >>>>> >>>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly >>>> prohibited... If you have received this communication in error, pleas= e >>>> notify the sender immediately by e-mail and delete the message and any= file >>>> attachments from your computer. Thank you.* >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > Identity Standards Architect > Verizon Media Work: george.fletcher@oath.com > Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch > Office: +1-703-265-2544 Photos: http://georgefletcher.photograp= hy > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_Jn= E&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DT9FBaSmKjH9DP1tZy7yS2= PWNPsktsU0izt30MhOcMpw&s=3DA-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e=3D > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000004214490583d670d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Brian for raisin= g this.

Yes, the expectation I believe is to follo= w the same approach as the token endpoint. As the spec is primarily for pub= lic clients, that's what we documented explicitly but it's worth ca= lling out.

Would the following text suffice in ord= er to "inherit" the client authentication requirements of the tok= en endpoint do you think?

=C2=A0 =C2=A0 "The = client authentication requirements of Section 3.2.1 of RFC6749 apply to req= uests on this endpoint."

Then= there's the matter of the REQUIRED "client_id" parameter. Pe= rhaps we could say "REQUIRED, unless the client authenticates per Sect= ion 2.3 of RFC6749"

On Mon, Mar 11, 2019 at 10:30 AM Phil Hu= nt <phil.hunt@oracle.com>= wrote:
+1 to using same authentication requirements as for token endpoin= t.=C2=A0

Phil

On Mar 11, 2019, at 10:27 AM, Ge= orge Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:

<= /div>
=20 =20 =20 =20 +1

to using the same client authn method as for the /token endpoint

On 3/11/19 1= 2:31 PM, Brian Campbell wrote:
=20


On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan <panva.ip@gmail.com> wrote:
Strike that, it should maybe just use the registered auth method for the token endpoint?

Yeah, that's what I'd think would be the way to go. =
=C2=A0

If there's auth we should also make it clear that client_id should not be omitted from the request body and it must be the same as the one provided with client authentication.


Fair point.


=C2=A0
S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:14, Filip Skokan <panva.ip@gmail.com> wrote:
If we're about to add client authentication fo= r the device_authorization_endpoint, i'd say we should also register for device_authorization_endpoint_auth_method, device_authorization_endpoint_auth_signing_alg client metadata. Maybe define the default value to be "none" / not provided to be in line with= the late draft implementations. Wdyt?

S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcampbell=3D40pingidentity.com= @dmarc.ietf.org> wrote:
I do realize it's very late in the process for this document but believe these omissions can be addressed in the document with only minor changes/additions and that it'd be better late than not at all..

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <bcampbell@pingidentity.com= > wrote:
Another omission[1] (maybe, I believe it is anyway) to the Device Flow is that client authentication isn't defined fo= r the device authorization request to device authorization endpoint.

I suspect that it's largely an oversight because public clients are really the conical use-case for the device flow and no authentication is needed or possible in that case. There are, however, likely to be cases where a client with credentials will do the device flow and it would be good for the AS to be able to properly authenticate such clients before setting up and saving the state for the transaction. Having normal client authentication at device authorization endpoint also brings better consistency to client identification/authentication for requests made directly from client to AS. =C2=A0


[1] error responses from the device authorization endpoint should probably also be defined https://mailarchive.ietf.org/= arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4


CONFIDENTIALITY NOTICE: This = email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.___________= ____________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
= 
____________=
___________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo=
/oauth


--=
=20
Identity Standards Architect
Verizon Media                     Work: george.fletcher@oath.com
Mobile: +1-703-462-3494           Twitter: http://twi=
tter.com/gffletch
Office: +1-703-265-2544           Photos: http:=
//georgefletcher.photography
=20
______= _________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000004214490583d670d2-- From nobody Mon Mar 11 13:21:53 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367271311D6 for ; Mon, 11 Mar 2019 13:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 CttjXGW_gcPD for ; Mon, 11 Mar 2019 13:21:44 -0700 (PDT) Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B8E130EA6 for ; Mon, 11 Mar 2019 13:21:44 -0700 (PDT) Received: by mail-it1-x12a.google.com with SMTP id l139so764249ita.5 for ; Mon, 11 Mar 2019 13:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=skh0fluXUuUHOCnwLVF6jVj2wQQCxmhhtKd5a8zIX18=; b=hllnpt2jzYxKzWlnE23ls/wL9CgDa8ODW95VZ0E+O+3y5vkGWHlB0SENrL8xGrNw+/ FtKnvGDrAGQjcvXFEL6laN7o7r0nQhmoEZDf5ZhjmVX7z+S2Mxu8tunSTuu7PuNRczQt pcExukCKSzqZiKfskJxiRCDjq+PhnZ7+PBAAg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=skh0fluXUuUHOCnwLVF6jVj2wQQCxmhhtKd5a8zIX18=; b=BQCxqnKFwbCwmnnUvaYsF+LvZ3wL4UNzpn8IyQqqbFLZP/3+VUO2zonq1/pjxXAxfD XmBWuNQPJ6esSEDgXqYCxOz1LLHLI8FsysK0zBEFMoZBCFKeT0XMB2Eeju/iljxuc1Oc 1e4de1QM1uI0GZ3CBvDj7RU3fwUkmlyBWF1kbHJdPTkAibE/nNGo0/JraFjZ1BL3CiAG 1TxlR9Z84yQV59GPP5+uM/ZPdpsv2Qbthe4EKqyRH4q6OChoxnKYxWWuUkJHFZYXl0+X qnzc36VZmS2IKlSHScj/QC5McCYe/UpvcPvNt62q7ebPaTsLg6DCpj/x4bIXe/aMudto wN+g== X-Gm-Message-State: APjAAAVAXBhOVZwRtVZ6WxNT1zRXK4ktCMgT8cojpgxjlAbbKdi//ZUy qTNPTf+xlCtDQ3V2RoE5BnTjCROZJLnP9SIhcTLh8cmU24MT7HlWUR+J/cSFthMrFZlETtTGJkw CGL7PRKBW/4uDKQ== X-Google-Smtp-Source: APXvYqykWdJgpPRoKTrWfOSvShPxI7nie4SlGh3nX9Euw1A1aNLn30ofIaA8GPzTSuItvuTgPdVdiZzBt2YKG53Vfzw= X-Received: by 2002:a24:b501:: with SMTP id v1mr31200ite.174.1552335703436; Mon, 11 Mar 2019 13:21:43 -0700 (PDT) MIME-Version: 1.0 References: <7c605f52-ff7f-49cd-0a4e-af3aa15663be@aol.com> <710ACBA5-C43D-4396-A3AE-9D7156204E3E@oracle.com> In-Reply-To: From: Brian Campbell Date: Mon, 11 Mar 2019 14:21:16 -0600 Message-ID: To: William Denniss Cc: Phil Hunt , George Fletcher , oauth Content-Type: multipart/alternative; boundary="0000000000002d0d1c0583d75247" Archived-At: Subject: Re: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 20:21:51 -0000 --0000000000002d0d1c0583d75247 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And thank you, William, for being responsive about it. On Mon, Mar 11, 2019 at 1:18 PM William Denniss wrote: > Thank you Brian for raising this. > > Yes, the expectation I believe is to follow the same approach as the toke= n > endpoint. As the spec is primarily for public clients, that's what we > documented explicitly but it's worth calling out. > > Would the following text suffice in order to "inherit" the client > authentication requirements of the token endpoint do you think? > > "The client authentication requirements of Section 3.2.1 of RFC6749 > apply to requests on this endpoint." > I think so, yes. Although given the primary focus being for public clients, it might be helpful to have a little qualifying text here catering to that most common case. I guess I'm just looking to try and avoid folks mistakenly interpreting that to mean that client authentication is always required and so somehow public clients can't do this flow. Something like the following (wording could maybe be improved but hopefully conveys the idea): 'The client authentication requirements of Section 3.2.1 of RFC6749 apply to requests on this endpoint, which means that confidential clients (those that have established client credentials) authenticate in the same manner as when making requests to the token endpoint and public clients provide the "client_id" parameter to identify themselves.' > Then there's the matter of the REQUIRED "client_id" parameter. Perhaps we > could say "REQUIRED, unless the client authenticates per Section 2.3 of > RFC6749" > I kinda prefer the text you have already in section 3.4: " client_id REQUIRED, if the client is not authenticating with the authorization server as described in Section 3.2.1. of [RFC6749]." > > On Mon, Mar 11, 2019 at 10:30 AM Phil Hunt wrote: > >> +1 to using same authentication requirements as for token endpoint. >> >> Phil >> >> On Mar 11, 2019, at 10:27 AM, George Fletcher < >> gffletch=3D40aol.com@dmarc.ietf.org> wrote: >> >> +1 >> >> to using the same client authn method as for the /token endpoint >> >> On 3/11/19 12:31 PM, Brian Campbell wrote: >> >> >> >> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan wrote= : >> >>> Strike that, it should maybe just use the registered auth method for th= e >>> token endpoint? >>> >> >> Yeah, that's what I'd think would be the way to go. >> >> >>> >>> If there's auth we should also make it clear that client_id should not >>> be omitted from the request body and it must be the same as the one >>> provided with client authentication. >>> >>> >> Fair point. >> >> >> >> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Mon, 11 Mar 2019 at 17:14, Filip Skokan wrote: >>> >>>> If we're about to add client authentication for the >>>> device_authorization_endpoint, i'd say we should also register for >>>> device_authorization_endpoint_auth_method, >>>> device_authorization_endpoint_auth_signing_alg client metadata. Maybe >>>> define the default value to be "none" / not provided to be in line wit= h the >>>> late draft implementations. Wdyt? >>>> >>>> S pozdravem, >>>> *Filip Skokan* >>>> >>>> >>>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell >>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>> >>>>> I do realize it's very late in the process for this document but >>>>> believe these omissions can be addressed in the document with only mi= nor >>>>> changes/additions and that it'd be better late than not at all.. >>>>> >>>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>>>> Another omission[1] (maybe, I believe it is anyway) to the Device >>>>>> Flow is that client authentication isn't defined for the device >>>>>> authorization request to device authorization endpoint. >>>>>> >>>>>> I suspect that it's largely an oversight because public clients are >>>>>> really the conical use-case for the device flow and no authenticatio= n is >>>>>> needed or possible in that case. There are, however, likely to be ca= ses >>>>>> where a client with credentials will do the device flow and it would= be >>>>>> good for the AS to be able to properly authenticate such clients bef= ore >>>>>> setting up and saving the state for the transaction. Having normal c= lient >>>>>> authentication at device authorization endpoint also brings better >>>>>> consistency to client identification/authentication for requests mad= e >>>>>> directly from client to AS. >>>>>> >>>>>> >>>>>> [1] error responses from the device authorization endpoint should >>>>>> probably also be defined >>>>>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe3993= 3k4 >>>>>> >>>>>> >>>>>> >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). An= y >>>>> review, use, distribution or disclosure by others is strictly >>>>> prohibited... If you have received this communication in error, plea= se >>>>> notify the sender immediately by e-mail and delete the message and an= y file >>>>> attachments from your computer. Thank you.* >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> -- >> Identity Standards Architect >> Verizon Media Work: george.fletcher@oath.com >> Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch <= https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__twitter.com_gffletch&= d=3DDwMDaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWman= qWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DT9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhO= cMpw&s=3Dfm9UvoaRS-A1-2CXwQEgOZ7fWb-PGvleny8Ccwq-SRs&e=3D> >> Office: +1-703-265-2544 Photos: http://georgefletcher.photogra= phy >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_J= nE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DT9FBaSmKjH9DP1tZy7yS= 2PWNPsktsU0izt30MhOcMpw&s=3DA-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e= =3D >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000002d0d1c0583d75247 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And thank you, William, for being responsiv= e about it.

On Mon, = Mar 11, 2019 at 1:18 PM William Denniss <wdenniss=3D40google.com@dmarc.ietf.org> wrote:
Thank you Brian for raising= this.

Yes, the expectation I believe is to follow= the same approach as the token endpoint. As the spec is primarily for publ= ic clients, that's what we documented explicitly but it's worth cal= ling out.

Would the following text suffice in orde= r to "inherit" the client authentication requirements of the toke= n endpoint do you think?

=C2=A0 =C2=A0 "The c= lient authentication requirements of Section 3.2.1 of RFC6749 apply to requ= ests on this endpoint."
<= /div>


<= /div>
Although given the primary focus being for public clients, it mig= ht be helpful to have a little qualifying text here catering to that most c= ommon case. I guess I'm just looking to try and avoid folks mistakenly = interpreting that to mean that client authentication is always required an= d so somehow public clients can't do this flow. Something like the foll= owing (wording could maybe be improved but hopefully conveys the idea):
=

'The client authentication requirements of Se= ction 3.2.1 of RFC6749 apply to requests on this endpoint, which means that= confidential clients (those that have established client credentials) auth= enticate in the same manner as when making requests to the token endpoint a= nd public clients provide the "client_id" parameter to identify t= hemselves.'
=C2=A0


Then there's the matter of= the REQUIRED "client_id" parameter. Perhaps we could say "R= EQUIRED, unless the client authenticates per Section 2.3 of RFC6749"

I kinda = prefer the text you have already in section 3.4:

=C2=A0 &= quot; client_id
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 REQUIRED, if the client i= s not authenticating with the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorizati= on server as described in Section 3.2.1. of [RFC6749]."


+1 to using same authentication requirements as for token endpoi= nt.=C2=A0

Phil

On Mar 11, 2019, at 10:= 27 AM, George Fletcher <gffletch=3D40aol.com@dmarc.ietf.org> wrote:=

=20 =20 =20 =20 +1

to using the same client authn method as for the /token endpoint

On 3= /11/19 12:31 PM, Brian Campbell wrote:
=20


On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan <panva.ip@gmail.com> wrote:
Strike that, it should maybe just use the registered auth method for the token endpoint?

Yeah, that's what I'd think would be the way to go. =
=C2=A0

If there's auth we should also make it clear that client_id should not be omitted from the request body and it must be the same as the one provided with client authentication.


Fair point.


=C2=A0
S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:14, Filip Skokan <panva.ip@gmail.com> wrote:
If we're about to add client authentication fo= r the device_authorization_endpoint, i'd say we should also register for device_authorization_endpoint_auth_method, device_authorization_endpoint_auth_signing_alg client metadata. Maybe define the default value to be "none" / not provided to be in line with= the late draft implementations. Wdyt?

S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcampbell=3D40pingidentity.com= @dmarc.ietf.org> wrote:
I do realize it's very late in the process for this document but believe these omissions can be addressed in the document with only minor changes/additions and that it'd be better late than not at all..

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <bcampbell@pingidentity.com= > wrote:
Another omission[1] (maybe, I believe it is anyway) to the Device Flow is that client authentication isn't defined fo= r the device authorization request to device authorization endpoint.

I suspect that it's largely an oversight because public clients are really the conical use-case for the device flow and no authentication is needed or possible in that case. There are, however, likely to be cases where a client with credentials will do the device flow and it would be good for the AS to be able to properly authenticate such clients before setting up and saving the state for the transaction. Having normal client authentication at device authorization endpoint also brings better consistency to client identification/authentication for requests made directly from client to AS. =C2=A0


[1] error responses from the device authorization endpoint should probably also be defined https://mailarchive.ietf.org/= arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4


CONFIDENTIALITY NOTICE: This = email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.___________= ____________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
____=
___________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/=
listinfo/oauth


--=20
Identity Standards Architect
Verizon Media                     Work: george.fletcher@oath.com
Mobile: +1-703-462-3494           Twitter: =
http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
=20
______= _________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000002d0d1c0583d75247-- From nobody Mon Mar 11 13:43:11 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1CB13115C for ; Mon, 11 Mar 2019 13:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.511 X-Spam-Level: X-Spam-Status: No, score=-15.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 nKM1Peco1BeU for ; Mon, 11 Mar 2019 13:43:06 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58A31293B1 for ; Mon, 11 Mar 2019 13:43:05 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id e24so881995itl.1 for ; Mon, 11 Mar 2019 13:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uRPA6l/XSNGTRHyy8yGnfzE9v+ikva3U+V2bmeBY2zc=; b=bmuISmJVF5rYPePsd54q3hhbxOVcBARfprNdB0DjI34WTtPmz0B6srPtvzxE+rrvO/ fQY98cmJ7rExo0I6+q3AVC+RAhatbDkIhTGs3idDTKc1vjCjNVQvgb0/Mkl7poG1D2m1 mFq94XW4JizSW03kdQI0hhC/JDGfRdteG6ORnGyEXBryl9KMYQm3ULECop/m0ys2gs52 eUaPMeakwaZeA+iaFtJXvkh3QBds76HLxy1Ango0hdTRs/r1y3C1mDJBFavmoCleWB/c GYG1A3SkQ+RrD4H1qpRdPwDLrR+mDQM7vVxg5Df1H9L8Tm+v+Z116TjDKypZVkQyIbE2 PUXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uRPA6l/XSNGTRHyy8yGnfzE9v+ikva3U+V2bmeBY2zc=; b=Br+tfG5qyCIGjWlTTcrLVwUIk8nS8t2qLsEzSpgpeJGO+puy3zKKQu8bJBQ8dtp/oZ sHYYG6inQrXRp826Ba+QnfK/knr+3S8/+9pKeGRp2JLNI7Pd9fHseZAqP/osWZvFaMt8 tWV9cyG88r7r0WFtjMdZKzJ+20uz213Ig47aCU4NKlA7CL9HWujggRwfHtXx/Dv/FT5v hCuKv5rZ+pYElOqsZnmJVTGOV7yWwidOqy7CoEWjLVGyMJhPm8cmYL90PFie+k7np+9x qV6asNDE7BHyhoyfacd3+tv9gz2SfQqms0rkoi+oX2W+PETMZsytIg4zIgia6RbtiNp4 iNaA== X-Gm-Message-State: APjAAAX5dxpqEuYd/A0nNMtGTdwGCYZgOcacJS509YMrynyKY2GJzQXr 43NzoUE/2kza8QH1CwVpHKtp3YSLfey7WOL9XkOeVw== X-Google-Smtp-Source: APXvYqwZ8fcNf6xcW64+vAcYA8qEYwgl6IuEnxISwCOultR/M51UEJ9BBougD/lBzDTTq+Wid9+Jxpv8BiwurYnYlXA= X-Received: by 2002:a24:1444:: with SMTP id 65mr61283itg.137.1552336984863; Mon, 11 Mar 2019 13:43:04 -0700 (PDT) MIME-Version: 1.0 References: <7c605f52-ff7f-49cd-0a4e-af3aa15663be@aol.com> <710ACBA5-C43D-4396-A3AE-9D7156204E3E@oracle.com> In-Reply-To: From: William Denniss Date: Mon, 11 Mar 2019 13:42:53 -0700 Message-ID: To: Brian Campbell Cc: Phil Hunt , George Fletcher , oauth Content-Type: multipart/alternative; boundary="0000000000008e4b010583d79edd" Archived-At: Subject: Re: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 20:43:09 -0000 --0000000000008e4b010583d79edd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 11, 2019 at 1:21 PM Brian Campbell wrote: > And thank you, William, for being responsive about it. > > > On Mon, Mar 11, 2019 at 1:18 PM William Denniss 40google.com@dmarc.ietf.org> wrote: > >> Thank you Brian for raising this. >> >> Yes, the expectation I believe is to follow the same approach as the >> token endpoint. As the spec is primarily for public clients, that's what= we >> documented explicitly but it's worth calling out. >> >> Would the following text suffice in order to "inherit" the client >> authentication requirements of the token endpoint do you think? >> >> "The client authentication requirements of Section 3.2.1 of RFC6749 >> apply to requests on this endpoint." >> > > I think so, yes. > > Although given the primary focus being for public clients, it might be > helpful to have a little qualifying text here catering to that most commo= n > case. I guess I'm just looking to try and avoid folks mistakenly > interpreting that to mean that client authentication is always required a= nd > so somehow public clients can't do this flow. Something like the followin= g > (wording could maybe be improved but hopefully conveys the idea): > > 'The client authentication requirements of Section 3.2.1 of RFC6749 apply > to requests on this endpoint, which means that confidential clients (thos= e > that have established client credentials) authenticate in the same manner > as when making requests to the token endpoint and public clients provide > the "client_id" parameter to identify themselves.' > > The context helps, thanks for the suggested text, I used it and it's staged locally now. > > >> Then there's the matter of the REQUIRED "client_id" parameter. Perhaps w= e >> could say "REQUIRED, unless the client authenticates per Section 2.3 of >> RFC6749" >> > > I kinda prefer the text you have already in section 3.4: > > " client_id > REQUIRED, if the client is not authenticating with the > authorization server as described in Section 3.2.1. of [RFC6749]." > > hah yeah I prefer that construction too, forgot I'd already given it that treatment elsewhere. Also staged locally. Thanks again for reporting this! > > >> >> On Mon, Mar 11, 2019 at 10:30 AM Phil Hunt wrote: >> >>> +1 to using same authentication requirements as for token endpoint. >>> >>> Phil >>> >>> On Mar 11, 2019, at 10:27 AM, George Fletcher < >>> gffletch=3D40aol.com@dmarc.ietf.org> wrote: >>> >>> +1 >>> >>> to using the same client authn method as for the /token endpoint >>> >>> On 3/11/19 12:31 PM, Brian Campbell wrote: >>> >>> >>> >>> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan >>> wrote: >>> >>>> Strike that, it should maybe just use the registered auth method for >>>> the token endpoint? >>>> >>> >>> Yeah, that's what I'd think would be the way to go. >>> >>> >>>> >>>> If there's auth we should also make it clear that client_id should not >>>> be omitted from the request body and it must be the same as the one >>>> provided with client authentication. >>>> >>>> >>> Fair point. >>> >>> >>> >>> >>>> S pozdravem, >>>> *Filip Skokan* >>>> >>>> >>>> On Mon, 11 Mar 2019 at 17:14, Filip Skokan wrote: >>>> >>>>> If we're about to add client authentication for the >>>>> device_authorization_endpoint, i'd say we should also register for >>>>> device_authorization_endpoint_auth_method, >>>>> device_authorization_endpoint_auth_signing_alg client metadata. Maybe >>>>> define the default value to be "none" / not provided to be in line wi= th the >>>>> late draft implementations. Wdyt? >>>>> >>>>> S pozdravem, >>>>> *Filip Skokan* >>>>> >>>>> >>>>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell >>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>> >>>>>> I do realize it's very late in the process for this document but >>>>>> believe these omissions can be addressed in the document with only m= inor >>>>>> changes/additions and that it'd be better late than not at all.. >>>>>> >>>>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell < >>>>>> bcampbell@pingidentity.com> wrote: >>>>>> >>>>>>> Another omission[1] (maybe, I believe it is anyway) to the Device >>>>>>> Flow is that client authentication isn't defined for the device >>>>>>> authorization request to device authorization endpoint. >>>>>>> >>>>>>> I suspect that it's largely an oversight because public clients are >>>>>>> really the conical use-case for the device flow and no authenticati= on is >>>>>>> needed or possible in that case. There are, however, likely to be c= ases >>>>>>> where a client with credentials will do the device flow and it woul= d be >>>>>>> good for the AS to be able to properly authenticate such clients be= fore >>>>>>> setting up and saving the state for the transaction. Having normal = client >>>>>>> authentication at device authorization endpoint also brings better >>>>>>> consistency to client identification/authentication for requests ma= de >>>>>>> directly from client to AS. >>>>>>> >>>>>>> >>>>>>> [1] error responses from the device authorization endpoint should >>>>>>> probably also be defined >>>>>>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe399= 33k4 >>>>>>> >>>>>>> >>>>>>> >>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> privileged material for the sole use of the intended recipient(s). A= ny >>>>>> review, use, distribution or disclosure by others is strictly >>>>>> prohibited... If you have received this communication in error, ple= ase >>>>>> notify the sender immediately by e-mail and delete the message and a= ny file >>>>>> attachments from your computer. Thank you.* >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibite= d.. >>> If you have received this communication in error, please notify the sen= der >>> immediately by e-mail and delete the message and any file attachments f= rom >>> your computer. Thank you.* >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o= auth >>> >>> >>> -- >>> Identity Standards Architect >>> Verizon Media Work: george.fletcher@oath.com >>> Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch = >>> Office: +1-703-265-2544 Photos: http://georgefletcher.photogr= aphy >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_= JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DT9FBaSmKjH9DP1tZy7y= S2PWNPsktsU0izt30MhOcMpw&s=3DA-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e= =3D >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* --0000000000008e4b010583d79edd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Mar 11, 2019 at 1:21 PM Brian= Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
And th= ank you, William, for being responsive about it.


On Mon, Mar 11, 2019 at 1:18 PM William Denni= ss <wdenniss=3D40google.com@dmarc.ietf.org> wrote:
Thank you Brian for raising this.

Yes, th= e expectation I believe is to follow the same approach as the token endpoin= t. As the spec is primarily for public clients, that's what we document= ed explicitly but it's worth calling out.

Woul= d the following text suffice in order to "inherit" the client aut= hentication requirements of the token endpoint do you think?

=
=C2=A0 =C2=A0 "The client authentication requirements of Se= ction 3.2.1 of RFC6749 apply to requests on this endpoint."
<= /div>

I= think so, yes.

Although given the primary fo= cus being for public clients, it might be helpful to have a little qualifyi= ng text here catering to that most common case. I guess I'm just lookin= g to try and avoid folks mistakenly interpreting that to mean that client = authentication is always required and so somehow public clients can't d= o this flow. Something like the following (wording could maybe be improved = but hopefully conveys the idea):

'The clie= nt authentication requirements of Section 3.2.1 of RFC6749 apply to request= s on this endpoint, which means that confidential clients (those that have = established client credentials) authenticate in the same manner as when mak= ing requests to the token endpoint and public clients provide the "cli= ent_id" parameter to identify themselves.'
=C2=A0

Th= e context helps, thanks for the suggested text, I used it and it's stag= ed locally now.
=C2=A0

<= div dir=3D"ltr">

Then there's the ma= tter of the REQUIRED "client_id" parameter. Perhaps we could say = "REQUIRED, unless the client authenticates per Section 2.3 of RFC6749&= quot;

I= kinda prefer the text you have already in section 3.4:

= =C2=A0 " client_id
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 REQUIRED, if the = client is not authenticating with the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 aut= horization server as described in Section 3.2.1. of [RFC6749]."


hah yeah I prefer that construction too, forgot I&#= 39;d already given it that treatment elsewhere.

Al= so staged locally.

Thanks again for reporting this= !
=C2=A0
<= div dir=3D"ltr">
=C2=A0

On Mon, Mar 11, 2019 at 10:30 AM= Phil Hunt <ph= il.hunt@oracle.com> wrote:
+1 to using same authentication require= ments as for token endpoint.=C2=A0

Phi= l

On Mar 11, 2019, at 10:27 AM, George Fletcher &= lt;gffletch=3D40aol.com@dmarc.ietf.org> wrote:

=20 =20 =20 =20 +1

to using the same client authn method as for the /token endpoint

On 3/11/19 12:31 PM, Brian Campbell wrote:
=20


On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan <panva.ip@gmail.com> wrote:
Strike that, it should maybe just use the registered auth method for the token endpoint?

Yeah, that's what I'd think would be the way to go. =
=C2=A0

If there's auth we should also make it clear that client_id should not be omitted from the request body and it must be the same as the one provided with client authentication.


Fair point.


=C2=A0
S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:14, Filip Skokan <panva.ip@gmail.com> wrote:
If we're about to add client authentication fo= r the device_authorization_endpoint, i'd say we should also register for device_authorization_endpoint_auth_method, device_authorization_endpoint_auth_signing_alg client metadata. Maybe define the default value to be "none" / not provided to be in line with= the late draft implementations. Wdyt?

S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcampbell=3D40pingidentity.com= @dmarc.ietf.org> wrote:
I do realize it's very late in the process for this document but believe these omissions can be addressed in the document with only minor changes/additions and that it'd be better late than not at all..

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <bcampbell@pingidentity.com= > wrote:
Another omission[1] (maybe, I believe it is anyway) to the Device Flow is that client authentication isn't defined fo= r the device authorization request to device authorization endpoint.

I suspect that it's largely an oversight because public clients are really the conical use-case for the device flow and no authentication is needed or possible in that case. There are, however, likely to be cases where a client with credentials will do the device flow and it would be good for the AS to be able to properly authenticate such clients before setting up and saving the state for the transaction. Having normal client authentication at device authorization endpoint also brings better consistency to client identification/authentication for requests made directly from client to AS. =C2=A0


[1] error responses from the device authorization endpoint should probably also be defined https://mailarchive.ietf.org/= arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4


CONFIDENTIALITY NOTICE: This = email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.___________= ____________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_______________________________________________
OAuth mailing list
O=
Auth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/oauth


--=20
Identity Standards Architect
Verizon Media                     Work: george.fletcher@oath.com
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
=20
______= _________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you. --0000000000008e4b010583d79edd-- From nobody Mon Mar 11 13:57:55 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECC6131181 for ; Mon, 11 Mar 2019 13:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 9CiZ963G2qKY for ; Mon, 11 Mar 2019 13:57:44 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858B91311C3 for ; Mon, 11 Mar 2019 13:57:44 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id y6so92819ioq.10 for ; Mon, 11 Mar 2019 13:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LwyfQNo//2ujo4n12yzXLvsv8sWe5P7p/LVN64rREQk=; b=Rt/ge1BFiTAqTF+wMq2MdK7naFEOaHUa61E5z+YoBT6/mIXafEDVzj3GWKBigGQRSa DdSm4rM0OL5qjiLt4nqk5GNBJ3K/O1hOqcbR31cpot9lmGnwfbtyVRAKSxTk8xjfTA2w Kwmi7cTdzrIa5n9a8JlxEej9w20zpCaU6KI28= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LwyfQNo//2ujo4n12yzXLvsv8sWe5P7p/LVN64rREQk=; b=tKi+nph8Ob3ZCLIvbGCmN9Q/NETMLmhWU4U8/K0VEwwzD/t+8cm6KQysmN8KPIimZJ t4ThW8AabK8YOvvC8oBqRfYklD1p62XGVejcRHsQMVjZLHmKdWJCjK8smwocNxqvFncv X+sF9ST5QWbIYeOUomQPYpABTEavdCDCRYU93jB6WM2GSE+3ZzbN97OHPobCvRSnlXxX k5Rj6n2BFkFskAZhY4+Z21p5LE8hphWvyGz09fThUw22jS3yIMcfbw87yATvlQH+bjur sVCEjGERwGKG8v7drL66TsVqWkBwkTX1TRv+5hKbQYSePqarFIQfRzrfZOxDiMLAHfWF 36gg== X-Gm-Message-State: APjAAAUTaTZMb6iApMgTb+YbdeWf7KyYE2eA5xo6hBFwhbWsUog/V1pF hwoq+wNfI56EN1QraTl5J7oD4iA23nsakKWyHBbTrpZaHIZawg/QXhOcrxIAdHVThk257+W5ltI 5G+qFiRNFoX2VbA== X-Google-Smtp-Source: APXvYqy8+2nUT8T41Aa1VEAPso4wHyjPCEE8RzpZLOb4XCHl6FzTkLQM4VKYGNGz3gODidi4jWbNM3rTTauhAaRFkro= X-Received: by 2002:a6b:5c0a:: with SMTP id z10mr5942073ioh.138.1552337863706; Mon, 11 Mar 2019 13:57:43 -0700 (PDT) MIME-Version: 1.0 References: <7c605f52-ff7f-49cd-0a4e-af3aa15663be@aol.com> <710ACBA5-C43D-4396-A3AE-9D7156204E3E@oracle.com> In-Reply-To: From: Brian Campbell Date: Mon, 11 Mar 2019 14:57:16 -0600 Message-ID: To: William Denniss Cc: Phil Hunt , George Fletcher , oauth Content-Type: multipart/alternative; boundary="000000000000f025fb0583d7d2a6" Archived-At: Subject: Re: [OAUTH-WG] Client authentication in the Device Authorization Request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 20:57:53 -0000 --000000000000f025fb0583d7d2a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All sounds good to me. Thanks again for picking this one up quickly. On Mon, Mar 11, 2019 at 2:43 PM William Denniss wrote: > > > On Mon, Mar 11, 2019 at 1:21 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> And thank you, William, for being responsive about it. >> >> >> On Mon, Mar 11, 2019 at 1:18 PM William Denniss > 40google.com@dmarc.ietf.org> wrote: >> >>> Thank you Brian for raising this. >>> >>> Yes, the expectation I believe is to follow the same approach as the >>> token endpoint. As the spec is primarily for public clients, that's wha= t we >>> documented explicitly but it's worth calling out. >>> >>> Would the following text suffice in order to "inherit" the client >>> authentication requirements of the token endpoint do you think? >>> >>> "The client authentication requirements of Section 3.2.1 of RFC6749 >>> apply to requests on this endpoint." >>> >> >> I think so, yes. >> >> Although given the primary focus being for public clients, it might be >> helpful to have a little qualifying text here catering to that most comm= on >> case. I guess I'm just looking to try and avoid folks mistakenly >> interpreting that to mean that client authentication is always required = and >> so somehow public clients can't do this flow. Something like the followi= ng >> (wording could maybe be improved but hopefully conveys the idea): >> >> 'The client authentication requirements of Section 3.2.1 of RFC6749 appl= y >> to requests on this endpoint, which means that confidential clients (tho= se >> that have established client credentials) authenticate in the same manne= r >> as when making requests to the token endpoint and public clients provide >> the "client_id" parameter to identify themselves.' >> >> > > The context helps, thanks for the suggested text, I used it and it's > staged locally now. > > >> >> >>> Then there's the matter of the REQUIRED "client_id" parameter. Perhaps >>> we could say "REQUIRED, unless the client authenticates per Section 2.3= of >>> RFC6749" >>> >> >> I kinda prefer the text you have already in section 3.4: >> >> " client_id >> REQUIRED, if the client is not authenticating with the >> authorization server as described in Section 3.2.1. of [RFC6749]." >> >> > hah yeah I prefer that construction too, forgot I'd already given it that > treatment elsewhere. > > Also staged locally. > > Thanks again for reporting this! > > >> >> >>> >>> On Mon, Mar 11, 2019 at 10:30 AM Phil Hunt wrote= : >>> >>>> +1 to using same authentication requirements as for token endpoint. >>>> >>>> Phil >>>> >>>> On Mar 11, 2019, at 10:27 AM, George Fletcher < >>>> gffletch=3D40aol.com@dmarc.ietf.org> wrote: >>>> >>>> +1 >>>> >>>> to using the same client authn method as for the /token endpoint >>>> >>>> On 3/11/19 12:31 PM, Brian Campbell wrote: >>>> >>>> >>>> >>>> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan >>>> wrote: >>>> >>>>> Strike that, it should maybe just use the registered auth method for >>>>> the token endpoint? >>>>> >>>> >>>> Yeah, that's what I'd think would be the way to go. >>>> >>>> >>>>> >>>>> If there's auth we should also make it clear that client_id should no= t >>>>> be omitted from the request body and it must be the same as the one >>>>> provided with client authentication. >>>>> >>>>> >>>> Fair point. >>>> >>>> >>>> >>>> >>>>> S pozdravem, >>>>> *Filip Skokan* >>>>> >>>>> >>>>> On Mon, 11 Mar 2019 at 17:14, Filip Skokan wrote= : >>>>> >>>>>> If we're about to add client authentication for the >>>>>> device_authorization_endpoint, i'd say we should also register for >>>>>> device_authorization_endpoint_auth_method, >>>>>> device_authorization_endpoint_auth_signing_alg client metadata. Mayb= e >>>>>> define the default value to be "none" / not provided to be in line w= ith the >>>>>> late draft implementations. Wdyt? >>>>>> >>>>>> S pozdravem, >>>>>> *Filip Skokan* >>>>>> >>>>>> >>>>>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell >>>>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>>>> >>>>>>> I do realize it's very late in the process for this document but >>>>>>> believe these omissions can be addressed in the document with only = minor >>>>>>> changes/additions and that it'd be better late than not at all.. >>>>>>> >>>>>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell < >>>>>>> bcampbell@pingidentity.com> wrote: >>>>>>> >>>>>>>> Another omission[1] (maybe, I believe it is anyway) to the Device >>>>>>>> Flow is that client authentication isn't defined for the device >>>>>>>> authorization request to device authorization endpoint. >>>>>>>> >>>>>>>> I suspect that it's largely an oversight because public clients ar= e >>>>>>>> really the conical use-case for the device flow and no authenticat= ion is >>>>>>>> needed or possible in that case. There are, however, likely to be = cases >>>>>>>> where a client with credentials will do the device flow and it wou= ld be >>>>>>>> good for the AS to be able to properly authenticate such clients b= efore >>>>>>>> setting up and saving the state for the transaction. Having normal= client >>>>>>>> authentication at device authorization endpoint also brings better >>>>>>>> consistency to client identification/authentication for requests m= ade >>>>>>>> directly from client to AS. >>>>>>>> >>>>>>>> >>>>>>>> [1] error responses from the device authorization endpoint should >>>>>>>> probably also be defined >>>>>>>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39= 933k4 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>> privileged material for the sole use of the intended recipient(s). = Any >>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>> prohibited... If you have received this communication in error, pl= ease >>>>>>> notify the sender immediately by e-mail and delete the message and = any file >>>>>>> attachments from your computer. Thank you.* >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed.. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth >>>> >>>> >>>> -- >>>> Identity Standards Architect >>>> Verizon Media Work: george.fletcher@oath.com >>>> Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch= >>>> Office: +1-703-265-2544 Photos: http://georgefletcher.photog= raphy >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_oauth&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DT9FBaSmKjH9DP1tZy7= yS2PWNPsktsU0izt30MhOcMpw&s=3DA-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e= =3D >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any f= ile >> attachments from your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000f025fb0583d7d2a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All sounds=C2=A0good to me. Thanks again for picking this = one up quickly.

On Mon, Mar 11, 2019 at 2:43 PM William Denniss <wde= nniss=3D40google.com@dmarc.i= etf.org> wrote:


On Mon, Mar 11, 2019 at 1:21 P= M Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrot= e:
And thank you, William, for being responsive about it.


On Mon, Mar 11, 2019= at 1:18 PM William Denniss <wdenniss=3D40google.com@dmarc.ietf.org> wrote:=
Thank you Brian for raising this.

Yes, the expectation I believe is to follow the same appr= oach as the token endpoint. As the spec is primarily for public clients, th= at's what we documented explicitly but it's worth calling out.

Would the following text suffice in order to "inh= erit" the client authentication requirements of the token endpoint do = you think?

=C2=A0 =C2=A0 "The client authenti= cation requirements of Section 3.2.1 of RFC6749 apply to requests on this e= ndpoint."

I think so, yes.

Alth= ough given the primary focus being for public clients, it might be helpful = to have a little qualifying text here catering to that most common case. I = guess I'm just looking to try and avoid folks mistakenly interpreting t= hat to mean that client authentication is always required and so somehow p= ublic clients can't do this flow. Something like the following (wording= could maybe be improved but hopefully conveys the idea):
'The client authentication requirements of Section 3.2.1 of= RFC6749 apply to requests on this endpoint, which means that confidential = clients (those that have established client credentials) authenticate in th= e same manner as when making requests to the token endpoint and public clie= nts provide the "client_id" parameter to identify themselves.'= ;
=C2=A0

The context helps, thanks for the suggested text, I = used it and it's staged locally now.
=C2=A0
=


<= div>Then there's the matter of the REQUIRED "client_id" param= eter. Perhaps we could say "REQUIRED, unless the client authenticates = per Section 2.3 of RFC6749"

I kinda prefer the text you have already in secti= on 3.4:

=C2=A0 " client_id
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 REQUIRED, if the client is not authenticating with the
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 authorization server as described in Section 3.2.1= . of [RFC6749]."


hah yeah I prefer that = construction too, forgot I'd already given it that treatment elsewhere.=

Also staged locally.

Tha= nks again for reporting this!
=C2=A0
=C2=A0=

=
On M= on, Mar 11, 2019 at 10:30 AM Phil Hunt <phil.hunt@oracle.com> wrote:
+1 to using= same authentication requirements as for token endpoint.=C2=A0

Phil

On Mar 11, 2019, at 10:27 AM, George Fletcher <gffletch=3D40aol.c= om@dmarc.ietf.org> wrote:

=20 =20 =20 =20 +1

to using the same client authn method as for the /token endpoint

On 3/11/19 12:31 PM, Bria= n Campbell wrote:
=20


On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan <panva.ip@gmail.com> wrote:
Strike that, it should maybe just use the registered auth method for the token endpoint?

Yeah, that's what I'd think would be the way to go. =
=C2=A0

If there's auth we should also make it clear that client_id should not be omitted from the request body and it must be the same as the one provided with client authentication.


Fair point.


=C2=A0
S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:14, Filip Skokan <panva.ip@gmail.com> wrote:
If we're about to add client authentication fo= r the device_authorization_endpoint, i'd say we should also register for device_authorization_endpoint_auth_method, device_authorization_endpoint_auth_signing_alg client metadata. Maybe define the default value to be "none" / not provided to be in line with= the late draft implementations. Wdyt?

S pozdravem,
Filip Skokan


On Mon, 11 Mar 2019 at 17:08, Brian Campbell <bcampbell=3D40pingidentity.com= @dmarc.ietf.org> wrote:
I do realize it's very late in the process for this document but believe these omissions can be addressed in the document with only minor changes/additions and that it'd be better late than not at all..

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <bcampbell@pingidentity.com= > wrote:
Another omission[1] (maybe, I believe it is anyway) to the Device Flow is that client authentication isn't defined fo= r the device authorization request to device authorization endpoint.

I suspect that it's largely an oversight because public clients are really the conical use-case for the device flow and no authentication is needed or possible in that case. There are, however, likely to be cases where a client with credentials will do the device flow and it would be good for the AS to be able to properly authenticate such clients before setting up and saving the state for the transaction. Having normal client authentication at device authorization endpoint also brings better consistency to client identification/authentication for requests made directly from client to AS. =C2=A0


[1] error responses from the device authorization endpoint should probably also be defined https://mailarchive.ietf.org/= arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4


CONFIDENTIALITY NOTICE: This = email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.___________= ____________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..=C2=A0 If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_________________________=
______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--=20
Identity Standards Architect
Verizon Media                     Work: george.fletcher@oath.com
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffl=
etch
Office: +1-703-265-2544           Photos: http://georgeflet=
cher.photography
=20
______= _________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited...=C2=A0 If you have received this communication in e= rror, please notify the sender immediately by e-mail and delete the message= and any file attachments from your computer. Thank you.<= /blockquote>
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000f025fb0583d7d2a6-- From nobody Mon Mar 11 14:03:52 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823AA1311F5 for ; Mon, 11 Mar 2019 14:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 P0wNc83B6Czd for ; Mon, 11 Mar 2019 14:03:44 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4471311CE for ; Mon, 11 Mar 2019 14:03:38 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id q24so552343otk.0 for ; Mon, 11 Mar 2019 14:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bY4tloceV56AaLyFRxnKtvAJzOlMQHydK8mhaab6Wh0=; b=N6YvCv0b8OwemgVLGCapCv2/ibp3dYeYGOYgf8SMJpFio185hI7e8gah+uK+ITYXJC mUYzcUoE9v+71oSzyzuc+Hq0dPZZS5P67Fupi2TH/RQtGWN4UYlgqgmSHqoe09R5oRgU 48jmyo/GF3D4PAhMeRIKmov639vqUJ4Z/nZgbEkpSrCj1UI966SXUSv00Js8Cfjdsogv 7LTC8J6krNJKEW94yc2SrrkwZXshtxk489pE7elJhOVMyvAXynnJlsCqCEdmOQGfKyQ8 gHL8jvYSvMK9zb4ZapcUXaoCdCY0P6+UkwAFffUTje93P2eNUys8IKj+eS39raO5sKZm 4svw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bY4tloceV56AaLyFRxnKtvAJzOlMQHydK8mhaab6Wh0=; b=KgUPGMlRlN22cawdZjsImjRGR1Fl042xZR4bLZ6ZtMpQcZFQZuCjvPKiljyarpQy8k Ehf3QdWScViT2etwfgIMeoC3DnvTnBRib3IDrg/QKcq/bs6dD6lY5micFx5ilkOsJ0Po f7gJ0vOfUymuMa8Tj3KhXYENOOEI/tQ5OUAyuwukCXNAPeZ2d91wmO1wHsVVAxMBZjPE jSIrj8Yvy1ICTYIIPP1pLPCFG8+GrZRvm2dMEdzuyjFDgwcVuGfqpLfZo4RxKvGdpJo/ Tw2/aymg9hyIoXO67tsmOqyVLVKZePREOstHfZGRCALo0MMpnMx6mG55Xn03tL+Z8q2m VFLQ== X-Gm-Message-State: APjAAAVYAbtbsokZzjJ3bSG2pNV5MKj5yS4ssD8F6WipYCnjjnyo0ojf BtfFpDJmmXVFl1sT8cASvg4uTPHSWmsH2JWY7S/0fUtRJyY= X-Google-Smtp-Source: APXvYqx9TUPlBONNxom7uoL7VxaWax7tOjhbkMlKaIPhGPTbo5vkmZm5nBfnG1ONGt0pk/GInOBn2eM7GeW8o8RDbV8= X-Received: by 2002:a9d:470d:: with SMTP id a13mr21152347otf.241.1552338217245; Mon, 11 Mar 2019 14:03:37 -0700 (PDT) MIME-Version: 1.0 From: Emond Papegaaij Date: Mon, 11 Mar 2019 22:03:26 +0100 Message-ID: To: OAuth@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OAUTH-WG] Typo in Device flow 5.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:03:51 -0000 Hi all, It seems the word 'no' is missing in section 5.2 of the OAuth 2.0 Device flow: As the device code is not displayed to the user and thus there are *NO* usability considerations on the length, a very high entropy code SHOULD be used. Best regards, Emond Papegaaij Topicus KeyHub From nobody Mon Mar 11 14:15:25 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1691200ED for ; Mon, 11 Mar 2019 14:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 zRFlZZoE708o for ; Mon, 11 Mar 2019 14:15:19 -0700 (PDT) Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656D8131168 for ; Mon, 11 Mar 2019 14:15:17 -0700 (PDT) Received: by mail-it1-x141.google.com with SMTP id d125so736565ith.1 for ; Mon, 11 Mar 2019 14:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/J3mo1Xa8DCPTLFEE1Z1BXBOuVxRWpXtl0V2+IaHH7k=; b=uzhuBns0t6eDH6hARcfQp19RSpiW6hmi5BlHiUYsEjjZf7syxXRKmn5ItoMx8uQi1d bPmdXIUboe1u+7GrNUrEeUHmLMWPG1+ojiVPdqO83ru1JSLiut/s6r3qtXL+obvWnV9P sfOE3JsC+bDV7K0VSo1Banp9esijtpH1XU4aGW+rBgHTk5WYtZfvqbOPDKjwD9wzuWbf 4MJTuEC6eVG4NtXL11i/MT8mCOd8XBFiVw0LxvxP+naMKFf2TUfiBLSb0updZDja2RSW DrUuHjPHtU9UW68y1OKu7kCM//7HJgLrglIUfYXEM8uF/YXLFjeada6w6FAWipGwxKl7 P/rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/J3mo1Xa8DCPTLFEE1Z1BXBOuVxRWpXtl0V2+IaHH7k=; b=sHqFO8z6SvxyRkbUCt+DgmCWZP794q6LWFnM4GO5EhCVq1mPV05dpNCUCJayk13kvo GGimP0LUlGV5hhqyXnmH6BK1Y1zad0/wXwXn1BA6+F773N7eAFtX2Z9A6YYAEhn/3bt5 Iey95G7k05sNckjsJklE82424EEMgdkFNMNRmomdA/tNaHkPncs0IXSmjEP2VsiXWWfb q5IYGr//cKXvUXCuHpSj0opIDWkn+0ydGuZuoGBQoO+u4zLWzsLdqx6PY2EGuMGi/1SC hcbaz1h/LyDSG97S0XvYTZI3Uyl8RiZyfMaz121FvvxESHvsDzghUy8h500W1WKEcRmC H9MA== X-Gm-Message-State: APjAAAV/HmnN7zZx6F8f/bBGyCtW/+2yjn7kD86lccw8a1nqS/mV1LpQ Tm1o7h7vZA0ySJfGAmn9QCxQ7iVNV8pCspmw+EWU/g== X-Google-Smtp-Source: APXvYqye4PxJgkseSZ5xFSu5ShNjKlMFDdUYDvfpW3VhgoJF9pEbg3yCHGY1Ariytm2blQc5d0ztbEqzTA1SyybYeoc= X-Received: by 2002:a02:9f0c:: with SMTP id z12mr18365119jal.93.1552338916279; Mon, 11 Mar 2019 14:15:16 -0700 (PDT) MIME-Version: 1.0 References: <6312173.9VWeF3DjuQ@papegaaij> In-Reply-To: From: William Denniss Date: Mon, 11 Mar 2019 14:15:05 -0700 Message-ID: To: Filip Skokan Cc: Emond Papegaaij , oauth Content-Type: multipart/alternative; boundary="000000000000ad97710583d81136" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device flow error response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:15:23 -0000 --000000000000ad97710583d81136 Content-Type: text/plain; charset="UTF-8" Good catch. To the "Device Authorization Response" section I will add: In the event of an error (such as an invalidly configured client), the authorization server responds in the same way as the token endpoint specified in Section 5.2 of RFC 6749. On Mon, Mar 11, 2019 at 10:30 AM Filip Skokan wrote: > Hi Emond, > > the way i approached implementation of device flow into an OIDC server was > to allow all already registered and handled parameters excluding the ones > [1] that really don't make sense for the flow at the device authorization > endpoint. > > What can be validated at the device authorization endpoint time is, > everything else runs as part of the regular authorization pipeline for > which i also construct the request based on the params saved together with > the device code backend model. Everything else that depends on the actual > device where authnz happens is processed as part of the web request > following the user code submission. When errors occur that cannot be > resolved with user interaction the error is assigned to the device code and > returned to the device with the next poll. I did not exclude prompt:none, > as the pipeline processing starts after the submission it's possible that > no prompt will occur there, but i can see how it may be weird.. Yes the > result at the token endpoint will include an id token if the scope included > `openid` as one would expect, just like it will include a refresh token if > `offline_access` is present. `resource` specifically is available as per > the resource indicator spec at device authorization as well as token > endpoints. > > I guess this is very similar to what you're thinking. > > I don't think we need to (and can for that matter) enumerate all possible > OAuth2.0 extensions in the specification. > > [1] web_message_uri, web_message_target, response_type, response_mode, > state, redirect_uri > > S pozdravem, > *Filip Skokan* > > > On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij > wrote: > >> Yes, that's how I implemented it as well. I return 'invalid_request' >> when the client_id is missing entirely. >> >> Do you have any thoughts how this specification should work in >> combination with other specs, such as OIDC? For example, the OIDC >> Authentication Request specifies several additional parameters, some >> of which may be applicable for the device flow as well. Can the device >> flow be used to obtain an ID token? How should parameters like >> 'max_age', 'id_token_hint' and 'claims' be processed? My plan was to >> construct a pseudo-authentication/authorization request using the >> parameters specified at the device authorization endpoint and apply >> these parameters during the user interaction. Some parameters, such as >> 'prompt=3Dnone', do not make much sense though. >> >> I think it may be a good idea to describe how this spec is supposed to >> interoperate with other specifications, especially those that extend >> the Authorization Endpoint. This definition can never be complete, as >> new specs will be defined after this one, but it can at least try to >> describe the general rules that apply. >> >> PS. Other specifications also define additional parameters that may be >> useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and >> 'include_granted_scopes' from OAuth 2.0 Incremental Authorization. >> >> Best regards, >> Emond Papegaaij >> Topicus KeyHub >> >> On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell >> wrote: >> > >> > While probably not terribly important from an interoperability >> perspective, I agree that does seem like an omission. >> > >> > I took a quick look at our implementation and bad requests to the >> device authorization endpoint will indeed return what is a standard OAuth >> 2.0 error response normally from the token endpoint with invalid_client or >> invalid_scope error codes. And a little bit of poking at Google's device >> authorization endpoint suggests it behaves similarly. I suspect it's pretty >> typical. >> > >> > >> > >> > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij < >> emond.papegaaij@gmail.com> wrote: >> >> >> >> Dear all, >> >> >> >> I'm working on an implementation of the OAuth 2.0 Device Flow for >> Browserless >> >> and Input Constrained Devices and noticed a possible omission in the >> spec. >> >> Section 3.2 describes the Device Authorization Response, but only the >> success >> >> response is specified, not the error response. I would have expected a >> >> standard OAuth 2.0 error response, probably with the following error >> codes: >> >> invalid_request, invalid_client and invalid_scope. >> >> >> >> Best regards, >> >> Emond Papegaaij >> >> Topicus KeyHub >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000ad97710583d81136 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good catch. To the = "Device Authorization Response" section I will add:
=C2=A0 =C2=A0 In the event of an error (such as an invalidly co= nfigured client),
=C2=A0 =C2=A0 the authorization server responds= in the same way as the token endpoint
=C2=A0 =C2=A0 specified in= Section 5.2 of RFC 6749.


On Mon, Mar 11, 2= 019 at 10:30 AM Filip Skokan <panv= a.ip@gmail.com> wrote:
Hi Emond,
the way i approached implementation of device flow into an OID= C server was to allow all already registered and handled parameters excludi= ng the ones [1] that really don't make sense for the flow at the device= authorization endpoint.

What can be validated at = the device authorization endpoint time is, everything else runs as part of = the regular authorization pipeline for which i also construct the request b= ased on the params saved together with the device code backend model. Every= thing else that depends on the actual device where authnz happens is proces= sed as part of the web request following the user code submission. When err= ors occur that cannot be resolved with user interaction the error is assign= ed to the device code and returned to the device with the next poll. I did = not exclude prompt:none, as the pipeline processing starts after the submis= sion it's possible that no prompt will occur there, but i can see how i= t may be weird.. Yes the result at the token endpoint will include an id to= ken if the scope included `openid` as one would expect, just like it will i= nclude a refresh token if `offline_access` is present. `resource` specifica= lly is available as per the resource indicator spec at device authorization= as well as token endpoints.

I guess this is very = similar to what you're thinking.

I don't t= hink we need to (and can for that matter) enumerate all possible OAuth2.0 e= xtensions in the specification.

[1]=C2=A0web_messa= ge_uri, web_message_target, response_type, response_mode, state, redirect_u= ri

S pozdrave= m,
Filip Skokan


On Mon, 11 Mar 2019 at 15:02, Emon= d Papegaaij <emond.papegaaij@gmail.com> wrote:
Yes, that's how I implemented it as well. I return 'in= valid_request'
when the client_id is missing entirely.

Do you have any thoughts how this specification should work in
combination with other specs, such as OIDC? For example, the OIDC
Authentication Request specifies several additional parameters, some
of which may be applicable for the device flow as well. Can the device
flow be used to obtain an ID token? How should parameters like
'max_age', 'id_token_hint' and 'claims' be processe= d? My plan was to
construct a pseudo-authentication/authorization request using the
parameters specified at the device authorization endpoint and apply
these parameters during the user interaction. Some parameters, such as
'prompt=3D3Dnone', do not make much sense though.

I think it may be a good idea to describe how this spec is supposed to
interoperate with other specifications, especially those that extend
the Authorization Endpoint. This definition can never be complete, as
new specs will be defined after this one, but it can at least try to
describe the general rules that apply.

PS. Other specifications also define additional parameters that may be
useful, such as: 'resource' from Resource Indicators for OAuth 2.0 = and
'include_granted_scopes' from OAuth 2.0 Incremental Authorization.<= br>
Best regards,
Emond Papegaaij
Topicus KeyHub

On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell
<bcampbe= ll@pingidentity.com> wrote:
>
> While probably not terribly important from an interoperability perspec= tive, I agree that does seem like an omission.
>
> I took a quick look at our implementation and bad requests to the devi= ce authorization endpoint will indeed return what is a standard OAuth 2.0 e= rror response normally from the token endpoint with invalid_client or inval= id_scope error codes. And a little bit of poking at Google's device aut= horization endpoint suggests it behaves similarly. I suspect it's prett= y typical.
>
>
>
> On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij <emond.papegaaij@gmail.com&g= t; wrote:
>>
>> Dear all,
>>
>> I'm working on an implementation of the OAuth 2.0 Device Flow = for Browserless
>> and Input Constrained Devices and noticed a possible omission in t= he spec.
>> Section 3.2 describes the Device Authorization Response, but only = the success
>> response is specified, not the error response. I would have expect= ed a
>> standard OAuth 2.0 error response, probably with the following err= or codes:
>> invalid_request, invalid_client and invalid_scope.
>>
>> Best regards,
>> Emond Papegaaij
>> Topicus KeyHub
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your = computer. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000ad97710583d81136-- From nobody Mon Mar 11 14:16:34 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FABC1311EB for ; Mon, 11 Mar 2019 14:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 SrWd2TWYD04W for ; Mon, 11 Mar 2019 14:16:13 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C4813120A for ; Mon, 11 Mar 2019 14:16:13 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id z131so979286itf.5 for ; Mon, 11 Mar 2019 14:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ElxHohj2zkc1MNfr5z1i5DNdeRhUNP98IP3TZhT3Xt4=; b=D8IHePKuTrGGkGPuYqxbbvbuJ6U6ODpk2CZF4GxTadtD6XnugLp68D+byNgKQbRIxU AHiKXzTB4WUG+sQ1kfdQ1qYEx4cmoJGKEvjVe/7ikyfC+uRNzCRvecHr8vDx0gJIKA51 SOSWIvMx8ju7jOp5f6l3ds+2g85A6uYQt67Kw/GGyOgA5Vd7rWzbvvyeSJ1ZXwzXxYLn 6VqgjMtFCwi78ckgxwGui0k5Jdp/DIiWwadF6SZgadkyOxz5t5UigqhkRB8aSbGAD5T9 E03FeYuNnIFIMjiENTPIedtbR/5H9WnaPMVZIAVdpO9i5jPZWD7bIXerQnxKJm9fgFdz dVsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ElxHohj2zkc1MNfr5z1i5DNdeRhUNP98IP3TZhT3Xt4=; b=Tv4aUslNdQePCUFjotGjulgpw2MB6RkOI1eQo8fRJ84fRAbAzT5RfXQ9hF7a49h76Q 3Rh6I3BCVZXjNR+Nkg7+l4iBfkEGts+0bl6rZ5YsbOomvuHKZNMqtBZp7OswWFy1gXE6 QsxGJjOQDSlmN35bXCXdDspH+yZiRHkaL0VUnlU69/iKxcNcSLTdnqw847QSjwFzAk7w gysll1qkVhvsJB8dQLrDv3jxoxThTTMVjidrXZ4rpHQ71j74uI814SJu+xxJrQ1Pj1Zg 0AoCBSQuvpKbROPIVqcq36iNsv3q8zb2kW1/w1AZ7mJMe6f04fIKzV9OOA27q6xgaOR1 0fNw== X-Gm-Message-State: APjAAAUGhGhQYyhZDO00DyYW0KRfjGlbxPnrX2N9fDpR16V2g0OAWx7/ MHvND56wD8DkvgMvALSlSpBcveSNM02Lhijpat7aUw== X-Google-Smtp-Source: APXvYqw+HUfeSQETR+Xi5gw/ZZVPMsVlEKCQyKxyYWd6R1TwqOPoAT62/I2b6NbncwLqnJpKHR1PhGpQ5LCQ+AXzToc= X-Received: by 2002:a24:1444:: with SMTP id 65mr142217itg.137.1552338972102; Mon, 11 Mar 2019 14:16:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: William Denniss Date: Mon, 11 Mar 2019 14:15:59 -0700 Message-ID: To: Emond Papegaaij Cc: oauth Content-Type: multipart/alternative; boundary="000000000000017dd70583d815c8" Archived-At: Subject: Re: [OAUTH-WG] Typo in Device flow 5.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:16:20 -0000 --000000000000017dd70583d815c8 Content-Type: text/plain; charset="UTF-8" Fixed in the next version, thanks for catching this. On Mon, Mar 11, 2019 at 2:04 PM Emond Papegaaij wrote: > Hi all, > > It seems the word 'no' is missing in section 5.2 of the OAuth 2.0 Device > flow: > > As the device code is not displayed to the user and thus there are > *NO* usability considerations on the length, a very high entropy code > SHOULD be used. > > Best regards, > Emond Papegaaij > Topicus KeyHub > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000017dd70583d815c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fixed in the next version, thanks for catching this.
=
On Mon= , Mar 11, 2019 at 2:04 PM Emond Papegaaij <emond.papegaaij@gmail.com> wrote:
Hi all,

It seems the word 'no' is missing in section 5.2 of the OAuth 2.0 D= evice flow:

As the device code is not displayed to the user and thus there are
*NO* usability considerations on the length, a very high entropy code
SHOULD be used.

Best regards,
Emond Papegaaij
Topicus KeyHub

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000017dd70583d815c8-- From nobody Mon Mar 11 14:34:32 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03A01311E9 for ; Mon, 11 Mar 2019 14:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mqfKs5j7hLNh for ; Mon, 11 Mar 2019 14:34:19 -0700 (PDT) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD8113120D for ; Mon, 11 Mar 2019 14:34:19 -0700 (PDT) Received: by mail-ot1-x341.google.com with SMTP id v62so609539otb.3 for ; Mon, 11 Mar 2019 14:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=3kogNgiN79yPF4QZ5xmB+RdMnvZjkdYQejyTcguT8nA=; b=AnWO1dAGFNr66BR/oHrMuvF3e1NghOGJjhtYnheNm6RMz63IvVX79O3d5o9seFsj7e zHxOFSTBLbZ+XrlcEjXsLDZMQVORIa7vmoNL23k10Mbdu4WDOq0iCKcZfGecjH0GSO8I SFCu8e608iLpVmVtwYBv22XXa20qTa0JZ4cSVu4wAGKL+/JkGrO8Kk1VG4bwJJWIXaBl jBOJj2DiaDYqM/nGbONNtN+3l0vA62uoVscJl1wfUdZnSoomGH+hyFNmw2UqCtH5uxel zArTTX05uj5Un8kTXaMYa6Ou3MX5quw6XuKzWhw6R5J3JV1xJsyMeS2wit/B1emYaS3H QPMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=3kogNgiN79yPF4QZ5xmB+RdMnvZjkdYQejyTcguT8nA=; b=QV2ly8IvWTbNUMHdkJS9FDlJEi4WRINBvhaIw1N3zg3qClmzH5oQ0xUT0pcdq4xEHO cDP/qe6oaYsBPi7kDBDCBKkCIVdnJ0oUm+GM6LBybrr1v7w/cdg2y5nZS5bNBe3riPg/ jojLE92UXpaxS9Ap1g+vou7xIuQdDsNwAgq2y+df+1sN2Qt3Z8kFIOFYMvxY5f+SVTlm AH7vcNPewsIsjm2THxV69Tqal2S0WnFZbF4RrzUIvFJGVPWkNLZP9vFF1r+fB3vjOIv6 /+udh0O5yRw8pQbT6lWEpH27fiQZLmUwK143Mym27NzQyWzy/Ngl0HHxGLm6Or91hVgS SY9A== X-Gm-Message-State: APjAAAXgBOkm6Z8px3hOqcHMHhfGYy9j1jHmExgaOg7v+0Jr6iUlyDL4 wbn0jw2IaWRBXRD6Q3XYmgzuiWtlO1u/AldNCo6ibWoe X-Google-Smtp-Source: APXvYqyA5lbc++tWFC7NecQ/W0cSKpkq9aQ9pCVKjEU6ASbbFk6qwwiHZ0DmghEShYeZeoM7/ysalzGlF9uDHnQhqps= X-Received: by 2002:a9d:470d:: with SMTP id a13mr21233950otf.241.1552340058014; Mon, 11 Mar 2019 14:34:18 -0700 (PDT) MIME-Version: 1.0 References: <6312173.9VWeF3DjuQ@papegaaij> In-Reply-To: From: Emond Papegaaij Date: Mon, 11 Mar 2019 22:34:07 +0100 Message-ID: To: OAuth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Device flow error response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:34:31 -0000 Hi Filip, Yes, this was exactly what I was thinking about. Good to know I'm working in the right direction. I must say that the spec reads really well and is fairly straightforward to implement. Best regards, Emond Papegaaij Topicus KeyHub On Mon, Mar 11, 2019 at 6:29 PM Filip Skokan wrote: > > Hi Emond, > > the way i approached implementation of device flow into an OIDC server wa= s to allow all already registered and handled parameters excluding the ones= [1] that really don't make sense for the flow at the device authorization = endpoint. > > What can be validated at the device authorization endpoint time is, every= thing else runs as part of the regular authorization pipeline for which i a= lso construct the request based on the params saved together with the devic= e code backend model. Everything else that depends on the actual device whe= re authnz happens is processed as part of the web request following the use= r code submission. When errors occur that cannot be resolved with user inte= raction the error is assigned to the device code and returned to the device= with the next poll. I did not exclude prompt:none, as the pipeline process= ing starts after the submission it's possible that no prompt will occur the= re, but i can see how it may be weird. Yes the result at the token endpoint= will include an id token if the scope included `openid` as one would expec= t, just like it will include a refresh token if `offline_access` is present= . `resource` specifically is available as per the resource indicator spec a= t device authorization as well as token endpoints. > > I guess this is very similar to what you're thinking. > > I don't think we need to (and can for that matter) enumerate all possible= OAuth2.0 extensions in the specification. > > [1] web_message_uri, web_message_target, response_type, response_mode, st= ate, redirect_uri > > S pozdravem, > Filip Skokan > > > On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij = wrote: >> >> Yes, that's how I implemented it as well. I return 'invalid_request' >> when the client_id is missing entirely. >> >> Do you have any thoughts how this specification should work in >> combination with other specs, such as OIDC? For example, the OIDC >> Authentication Request specifies several additional parameters, some >> of which may be applicable for the device flow as well. Can the device >> flow be used to obtain an ID token? How should parameters like >> 'max_age', 'id_token_hint' and 'claims' be processed? My plan was to >> construct a pseudo-authentication/authorization request using the >> parameters specified at the device authorization endpoint and apply >> these parameters during the user interaction. Some parameters, such as >> 'prompt=3D3Dnone', do not make much sense though. >> >> I think it may be a good idea to describe how this spec is supposed to >> interoperate with other specifications, especially those that extend >> the Authorization Endpoint. This definition can never be complete, as >> new specs will be defined after this one, but it can at least try to >> describe the general rules that apply. >> >> PS. Other specifications also define additional parameters that may be >> useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and >> 'include_granted_scopes' from OAuth 2.0 Incremental Authorization. >> >> Best regards, >> Emond Papegaaij >> Topicus KeyHub >> >> On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell >> wrote: >> > >> > While probably not terribly important from an interoperability perspec= tive, I agree that does seem like an omission. >> > >> > I took a quick look at our implementation and bad requests to the devi= ce authorization endpoint will indeed return what is a standard OAuth 2.0 e= rror response normally from the token endpoint with invalid_client or inval= id_scope error codes. And a little bit of poking at Google's device authori= zation endpoint suggests it behaves similarly. I suspect it's pretty typica= l. >> > >> > >> > >> > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij wrote: >> >> >> >> Dear all, >> >> >> >> I'm working on an implementation of the OAuth 2.0 Device Flow for Bro= wserless >> >> and Input Constrained Devices and noticed a possible omission in the = spec. >> >> Section 3.2 describes the Device Authorization Response, but only the= success >> >> response is specified, not the error response. I would have expected = a >> >> standard OAuth 2.0 error response, probably with the following error = codes: >> >> invalid_request, invalid_client and invalid_scope. >> >> >> >> Best regards, >> >> Emond Papegaaij >> >> Topicus KeyHub >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited. If you hav= e received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file attachments from your compu= ter. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Mar 11 14:59:07 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3979C1311F2; Mon, 11 Mar 2019 14:58:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <155234153421.23207.16686628137176106645@ietfa.amsl.com> Date: Mon, 11 Mar 2019 14:58:54 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-15.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:58:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Device Authorization Grant Authors : William Denniss John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-15.txt Pages : 23 Date : 2019-03-11 Abstract: The OAuth 2.0 Device Authorization Grant is designed for internet- connected devices that either lack a browser to perform a user-agent based authorization, or are input-constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources without using an on-device user-agent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 15:05:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0C813116F for ; Mon, 11 Mar 2019 15:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 0RIvPDv5SBhX for ; Mon, 11 Mar 2019 15:05:54 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C591310D4 for ; Mon, 11 Mar 2019 15:05:53 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id v10so513148lji.3 for ; Mon, 11 Mar 2019 15:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=ICXZNh0OfK5yvrw1XiE/fVQVnRuKbQ4WnR+ZdLdhejM=; b=l+AOwSeOqmiV1Krw5/SS1gkqfmWXzX7ennEbkbFtwJdHYmZdRvmiSiILp8GlR4y3g/ tyggcE3FDJg1dn5kI5mBKyR6APhPjwfYY9yxa/Eq4utRhZTJFF/FsrEE3HSPMOUPp8L8 16kmyZ2+8jGIPlFZXtCkAt8cny890kSktYApka117l1d3HnQ3NN3/AtqQoNw9xSECPLB HgN0S4OYubBW4D7BRg1ciF7g8ozX578CvZMfSoADCs3bSM9PLaUYm2JP17Xf4eNKPkLu G03UkuDc1gHi+7c/D7lEKsR1uvjCXq7gG2dyXjbRlukdX6J8n3/xOl7al1kvSq7/txyp CNRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=ICXZNh0OfK5yvrw1XiE/fVQVnRuKbQ4WnR+ZdLdhejM=; b=K/5R4B/kJBw9o7uryb2Sn/eODGegB1xF9QtJlzaKo4MITOpOhFeXnwSRZ358ZYISoi 9kXxDloRvJFnUaNBToiafI0mRoHXI4hjC0TtJzOcjdK6X8avbEK/GN8nyG/aNoGgCx2W CKj/9Q5jeMi1rK4+PsUiLR9A5UTbR8Zt5ka6vZNIi39vfKbR6cZYrW1C6VWAV2sIe3ZN mhB8L7krydGYgL1fNEJzfsZE78YBuTsrcE2Q+2f4UBDI7b1XHHrCymd2pz39S7uIeBPW jk8Bv13BppPL9tWH4Azvkd/Qiw5h/30m0ozMyWt3O2db9ujGTWgroR6mP7yIh+13E7eM tZvA== X-Gm-Message-State: APjAAAW0Oc42ZwKMWq00y3WPk9SKuhRKyRQXpKBqmCF+YIi9nQtegH90 K2/x9dB86E7x9avSasIwQ7H7BOXt8fD/g8/v0RuTxhLE9SJ/uQ== X-Google-Smtp-Source: APXvYqxwV43m53dAb3iZFZOt7GLFq/h7v1CVM3siuGiIxGvpwmeCYrdDjutAx58nnokpOiI6AylR2UTCfWhjqksjcq4= X-Received: by 2002:a2e:2165:: with SMTP id h98mr18006672ljh.117.1552341951637; Mon, 11 Mar 2019 15:05:51 -0700 (PDT) MIME-Version: 1.0 Reply-To: Vittorio@auth0.com From: Vittorio Bertocci Date: Mon, 11 Mar 2019 15:05:40 -0700 Message-ID: To: IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000099010c0583d8c68a" Archived-At: Subject: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 22:05:56 -0000 --00000000000099010c0583d8c68a Content-Type: text/plain; charset="UTF-8" Hi all, during today's office hours call I pointed out that oauth-mtls-13's abstract only mentions access token, although the spec does provide (some) guidance on refresh token binding as well. Although in the end implementers would do the right thing, given that they have to read the spec in its entirety, having a mention of refresh tokens in the abstract as well would make it easier for superficial readers to learn that the spec does address RTs as well. Refresh tokens leakage is one of the top concerns of the customers I deal with, and those people rarely read specs from cover to cover: having language in the abstract explicitly calling out RTs might make some conversations easier. This is admittedly very minor, but the fix would also be pretty easy, --00000000000099010c0583d8c68a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
during today's office hours call I pointed= out that=C2=A0oaut= h-mtls-13's=C2=A0abstract only mentions access token, although t= he spec does provide (some) guidance on=C2=A0 refresh token binding as well= .=C2=A0
Although in the end implementers would do the right thing= , given that they have to read the spec in its entirety, having a mention o= f refresh tokens in the abstract as well would make it easier for superfici= al readers to learn that the spec does address RTs as well. Refresh tokens = leakage is one of the top concerns of the customers I deal with, and those = people rarely read specs from cover to cover: having language in the abstra= ct explicitly calling out RTs might make some conversations easier.

This is admittedly very minor, but the fix would also be = pretty easy,=C2=A0
--00000000000099010c0583d8c68a-- From nobody Mon Mar 11 21:45:44 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E5612867A for ; Mon, 11 Mar 2019 21:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 4ZP_R5BPFzC3 for ; Mon, 11 Mar 2019 21:45:38 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF0D1277C9 for ; Mon, 11 Mar 2019 21:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zvu/4qA0TQUO+qGeS0cI86nbbWKAYjGcZnlRY562vj0=; b=Ab7yjFlb7QymcW0QH05k4jgkOuXD3hpe2+sF3L6YHtWb52+THGbJxii6sk36pnAlLd8x6wdcqoPzFJpaoBWXcccJhz6JQuPPFpfAzxZopQmzTsYAA8EV+WJ1cvBCemMdWtsGhVK/WcUN0fvCndSg4bIrfV/a5aZjsqoiW4TXKVo= Received: from MW2PR00MB0300.namprd00.prod.outlook.com (52.132.148.31) by MW2PR00MB0393.namprd00.prod.outlook.com (52.132.148.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1742.0; Tue, 12 Mar 2019 04:45:36 +0000 Received: from MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::b896:1e15:3eea:9808]) by MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::b896:1e15:3eea:9808%6]) with mapi id 15.20.1743.000; Tue, 12 Mar 2019 04:45:36 +0000 From: Mike Jones To: oauth Thread-Topic: =?Windows-1252?Q?OAuth_Device_Flow_spec_renamed_to_=93OAuth_2.0_Device_Au?= =?Windows-1252?Q?thorization_Grant=94?= Thread-Index: AdTYjgXjjDkV32I/SgyjH2FaCZbzpg== Date: Tue, 12 Mar 2019 04:45:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.93.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d433e8ba-acc6-4028-1a1a-08d6a6a591c5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:MW2PR00MB0393; x-ms-traffictypediagnostic: MW2PR00MB0393: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(136003)(366004)(376002)(209900001)(199004)(189003)(105586002)(606006)(68736007)(10290500003)(4326008)(25786009)(81156014)(6116002)(790700001)(81166006)(3846002)(66066001)(558084003)(106356001)(71200400001)(71190400001)(99286004)(97736004)(5660300002)(52536013)(10090500001)(7736002)(8990500004)(186003)(102836004)(256004)(2906002)(26005)(6346003)(33656002)(316002)(8936002)(22452003)(86612001)(53376002)(14454004)(966005)(7696005)(6306002)(55016002)(9686003)(54896002)(6436002)(53936002)(236005)(476003)(486006)(6916009)(478600001)(72206003)(86362001)(74316002)(6506007)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0393; H:MW2PR00MB0300.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cJYUJuNjGwCOVJqmrcJRKERY4l5SQNFIbXRxdSOOnm6+cd8wrp72MByIrZr3bLyHuDWR8dyM8UzHBIwo6z+3YtEPj9FClOctMgeVU+IE3QYd4QfmJ7NnaR28B6TNEyZPc3J6bsaREIezqQ0HQuAMhtu3UqrdaahkXP27HlB+RUfnoXhS6go2Trzmf3abt2n6fQ7XmGczHD02wuWd+y+kaq1ZdsJwQQAmhnpddFfR47FJEaX+5QhDJYje/JKxBxByDQ+c0Ow5KpBNif3oEW7hiRw90jhTIQABRgZ/VJ+Q57U4LIoni2+6Hr9RJrElNsFutZheJGU4gs9+i6huk9qIYgVAFDkHhEmr0FLpLWitPgUg+7RNpGY4dUWJBZ/qJMQo9Arqbn07wB6ZLB9BUWn/QzJvHaYHY5FsZYb1pwfC3dA= Content-Type: multipart/alternative; boundary="_000_MW2PR00MB030054A6819A3188A5010370F5490MW2PR00MB0300namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: d433e8ba-acc6-4028-1a1a-08d6a6a591c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 04:45:36.3802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0393 Archived-At: Subject: [OAUTH-WG] =?windows-1252?q?OAuth_Device_Flow_spec_renamed_to_?= =?windows-1252?q?=93OAuth_2=2E0_Device_Authorization_Grant=94?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 04:45:42 -0000 --_000_MW2PR00MB030054A6819A3188A5010370F5490MW2PR00MB0300namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I made a blog post about the renaming of the device spec and last-minute cl= arifications applied at http://self-issued.info/?p=3D1959 and @selfissued. Thanks again to William for doing the heav= y lifting! Hopefully this is the version that gets sent to the RFC Editor=85 -- Mike --_000_MW2PR00MB030054A6819A3188A5010370F5490MW2PR00MB0300namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I made a blog post about the renaming of the device = spec and last-minute clarifications applied at http://self-issued.info/?p=3D= 1959 and @selfissued.  Thanks ag= ain to William for doing the heavy lifting!

 

Hopefully this is the version that gets sent to the = RFC Editor=85

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           -- Mike

 

--_000_MW2PR00MB030054A6819A3188A5010370F5490MW2PR00MB0300namp_-- From nobody Mon Mar 11 22:33:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B18130ECE for ; Mon, 11 Mar 2019 22:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.com 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 gqI33psf_9Fz for ; Mon, 11 Mar 2019 22:33:15 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) (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 7C5D312008F for ; Mon, 11 Mar 2019 22:33:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.58,469,1544446800"; d="scan'208";a="290910145" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 12 Mar 2019 16:32:59 +1100 Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 12 Mar 2019 16:32:59 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsmsg3706.srv.dir.telstra.com (172.49.40.80) with Microsoft SMTP Server (TLS) id 8.3.485.1; Tue, 12 Mar 2019 16:32:58 +1100 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Mar 2019 16:32:58 +1100 Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.101.126) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 12 Mar 2019 16:32:58 +1100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iRW+Ue6YsG0Q33Cg8W4iSgbHrdMcOAd3+0KzkPOjjeg=; b=pnjUEiFlXCoxsHKWlp7Tbr1gAcwE1mGvtfvYceWvN1KUDoumdMmQt5w7Fbh6ouc3Y5sSRDNMLcsxCKoEDCtVGHs7MERWmWV2PXALJZbPvY2pjzu1wQav149RTEwU0q2C9kYyE0W7id4RKgO9ams4YIRh80RphrvOK0hVtMGF49k= Received: from ME1PR01MB0771.ausprd01.prod.outlook.com (10.169.166.135) by ME1PR01MB0993.ausprd01.prod.outlook.com (10.169.166.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.16; Tue, 12 Mar 2019 05:32:57 +0000 Received: from ME1PR01MB0771.ausprd01.prod.outlook.com ([fe80::755c:abb6:3873:bdcb]) by ME1PR01MB0771.ausprd01.prod.outlook.com ([fe80::755c:abb6:3873:bdcb%3]) with mapi id 15.20.1686.021; Tue, 12 Mar 2019 05:32:57 +0000 From: "Manger, James" To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.txt Thread-Index: AQHU2A+zHe7vCPp5QkiY718kRVVQD6YHdJRQ Date: Tue, 12 Mar 2019 05:32:57 +0000 Message-ID: References: <155231144978.23050.17841259546883608773@ietfa.amsl.com> In-Reply-To: <155231144978.23050.17841259546883608773@ietfa.amsl.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.500.19 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.35.9.18] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db6f81b5-f1b4-48c6-c473-08d6a6ac2efb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:ME1PR01MB0993; x-ms-traffictypediagnostic: ME1PR01MB0993: x-ms-exchange-purlcount: 6 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; ME1PR01MB0993; 23:GWSxIgucR16SmIdnKsHdp1tr5yQAP0I+lYKrgu74F?= =?us-ascii?Q?yuVvUCdle8cMGU9ezVFLDHkFddXQLZ3vjRuoXGwZ+obnlTbd90iJk/rxwqPj?= =?us-ascii?Q?ywjVRdOQrjzJ/uSWg5fgZ4e+b9Y7lAdMQgXyEQjodXVOrYGUA3U2DHrQgxEW?= =?us-ascii?Q?1QasHVqeYaJeLr4h4bNFXD5RtQ3JUtH8gQ6llO7BHrb8it2D10Vzsw2gPsXN?= =?us-ascii?Q?J9H5xJKotUa5ouRnxRT9QMjTgQa59CSVkNzYHDOGIVQ5DWWcrAXUHeNbPDDg?= =?us-ascii?Q?JOnFASQ5H9pijWX0Ke39GXKWZGacn5m3VZ76ztIjzkEcgSWdamldUlVa41RO?= =?us-ascii?Q?PHiE/mW6Zygkf/dib2K3jBXzSHDGqY5zW/xVP58uODDTjz4WIOZ8AcGMKJjX?= =?us-ascii?Q?DRwol9nwrinfqQRovZhzYby5ZewGscpMyH0B2JNtzofVsAtBdTSw7uQYxTx0?= =?us-ascii?Q?XrqmBtUMomXFsmUbi9Q7tyAzaALTWJAleoaA5yboMJYwNd4iWdXcw7w73wlq?= =?us-ascii?Q?E+xY3LDvsK5smulHgRPdnUy/Eox9vdp+dQg7VEXUU5c8yzZeRH0ow4oqjZ4n?= =?us-ascii?Q?KLZgSN56VjxgWNksWsV9KipzWvkSF5f8tAk9buIrmBH8AbqAP7b5XzZkrEdG?= =?us-ascii?Q?W61uRl3sxZJcvAtlzSLUhruADL4vGhWh+hPy9Hapidejra/xBeTjnvRUL5Z1?= =?us-ascii?Q?1+X5DCPQ4vBFlAnnP0cN6e/Vg1GSLeRZuWBPxkOkHltPdBH84AgY+GX/ny9k?= =?us-ascii?Q?/4EKsnmKDIepH99fx0gfeSxdivnPTuAIh5d9kSdNtiIoDouPvVwhXZcl+/IM?= =?us-ascii?Q?tScd/AlpbAs9zbhWDNnvxPRazeosWSte6WfI0FP1rf7+He8pBWH+cxUvRPln?= =?us-ascii?Q?bIxxGaNPIl1PrJyhD9IdfsiYfXnm2P8L2+rQ+FUSG5cHrsOg7slI9hvveNsd?= =?us-ascii?Q?DqOOweMCjhv5A/Gkmjlr53h7Ebb0RYbA1LSbG5i3l4Ya1EGrFV7uMCsJh0n6?= =?us-ascii?Q?bwHYVhnVokhFtVvy3DleiyQLK7TTPNXTRDwynyRQ7sllBujfM6fSpuhZzERp?= =?us-ascii?Q?Ujf2A03dW4zoVe8NUIKDNJrc+rY+UTNA8K3eOrN6AmMhjvc69Oju8gmaAmMm?= =?us-ascii?Q?zsN5XOOBreNM8faBDbl84x+LMTgt/vjR6Ii23oddU/wGo+drCQJEf+yLqqTJ?= =?us-ascii?Q?6f5TM9aEJmIr2Yb1XV/LuDmyaD5cJrxImyjUoChKyuh7w4Xwut0uo9nxYjO1?= =?us-ascii?Q?vJON1TBoyhRjq1afMmXonYQOYu8CPoO3lXHjloWC/+uCY7p/je2x9bylaFyA?= =?us-ascii?Q?1X1GZHdAO7EWZQGnWrJZEcSDaYXn7+Dj16JGCdwQmai8RuX/fLPEzjG1AmqT?= =?us-ascii?Q?BHhv6/6A0rMZ8uql+hmb+N7lXP0rzOsptOXsrCIMsMRnES1?= x-microsoft-antispam-prvs: x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(396003)(346002)(376002)(366004)(13464003)(189003)(199004)(229853002)(256004)(966005)(14444005)(9686003)(8936002)(71190400001)(97736004)(71200400001)(102836004)(6436002)(105586002)(106356001)(55016002)(6306002)(3846002)(52536013)(5660300002)(1730700003)(7736002)(53936002)(2351001)(8676002)(81156014)(66574012)(81166006)(6116002)(74316002)(5640700003)(305945005)(6916009)(2501003)(86362001)(68736007)(33656002)(7696005)(6246003)(66066001)(25786009)(316002)(2906002)(99286004)(26005)(446003)(486006)(11346002)(476003)(14454004)(76176011)(186003)(72206003)(6506007)(478600001)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:ME1PR01MB0993; H:ME1PR01MB0771.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BPtcgRJWcjk2ji824Ih4V7Tl7DTl2clO/gcsorvcMLXfU4yPgMpRAmkFjT7ounlZEtTr50UBBZ7pxik3fRr285LAYNbHBnIIjG9FiQQuIHYPR+lY50OPfpx/zg2FRonLTXCzQSa/jF7A7E7OXuT+Wp59BLdOarsQCPL1d4r74ybJHQ+xNmtU2VFiZCwI/66PKn3x301hPIbl0+6C1f+4ZI6zqynLKRT2yIscLOjCTTGJGqn5tlC/LdSHkUUoTlp+1/Ow7NulnK3IU6QoKeshDzsIH9pn2Kqo9PF73PQ/TRKVbS0/M0Rnz1OnHti2t2CR/wsor3GzI203zq4t6FELzZlnwdL2+d5EYA0uu6CT97ft+go5cqxHCwGjotFxTnQSlAOz8e0sllDhZw9YndmlVCZxCqn7xwd8+qhs+5xwNdw= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: db6f81b5-f1b4-48c6-c473-08d6a6ac2efb X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 05:32:57.0790 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME1PR01MB0993 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 05:33:19 -0000 Syntax glitches in draft-ietf-oauth-pop-key-distribution-06: 1. "exp" and "nbf" values should be numbers, not strings, so must not have = quotes [Section 4.2.2. "Client-to-AS Response"] 2. h'11' and b64'...' appear in the JSON examples, but should be "..." stri= ngs [Section 4.2.2. "Client-to-AS Response", members "kid", "x", "y"] 3. "iss" should be an https URI, such as "https://server.example.com", not = "xas.example.com" [Section 4.2.2. "Client-to-AS Response"]. "aud" should pr= obably be https://... as well, not http://.... -- James Manger -----Original Message----- From: OAuth On Behalf Of internet-drafts@ietf.org Sent: Tuesday, 12 March 2019 12:37 AM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Proof-of-Possession: Authorization Serv= er to Client Key Distribution Authors : John Bradley Phil Hunt Michael B. Jones Hannes Tschofenig Mihaly Meszaros Filename : draft-ietf-oauth-pop-key-distribution-06.txt Pages : 17 Date : 2019-03-11 Abstract: RFC 6750 specified the bearer token concept for securing access to protected resources. Bearer tokens need to be protected in transit as well as at rest. When a client requests access to a protected resource it hands-over the bearer token to the resource server. The OAuth 2.0 Proof-of-Possession security concept extends bearer token security and requires the client to demonstrate possession of a key when accessing a protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution= -06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-key-distribution-0= 6 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Mar 13 09:17:46 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6232B13106D for ; Wed, 13 Mar 2019 09:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.6 X-Spam-Level: X-Spam-Status: No, score=-15.6 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 yTydQSFBNLVy for ; Wed, 13 Mar 2019 09:17:42 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A111310B7 for ; Wed, 13 Mar 2019 09:17:37 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id k21so2159790ior.13 for ; Wed, 13 Mar 2019 09:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0jgrlCvTKk0kxuVOnDu+3DXp4PaXa70s7AXXnc+2UKU=; b=QpMRQk6+Ko81J7LmPQw8XHMkYnPlmS+HCK7+dZENYwopGqFzN30mQwIkWS11pks1hA Wfl4hZvhXQI9yDHuGrMa7odV5hxu9OWJWYz1R58ofcs/QN44ihbc4xuxX4UdtGbDHbUT wfWZaJ2Iz9JWhqhqKou1y2PJ8beHSU99toQhrhxV9xWPg/PjlduudhrK+mMFf2kB4FYd FcTjunaftt976nheknf8yBscTQkYckYmbOQpze80OkeoVZV9kjy9ONlqf2oX7NAmViMt e/NRmwtkLZKrZNV6r81vk6CF31V0R3giMoLo9QqZH+WeCZ7kUSyKBij3oDE80d6q9DXo ojMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0jgrlCvTKk0kxuVOnDu+3DXp4PaXa70s7AXXnc+2UKU=; b=BCh7UuBv2HYHpYreCJrua67+/p9TtXttNHqaNmvwwxupMoAH1SbnOwmhgUKZBtdMfs O0JyPJ8zt0yUw0BytWMZqNDp1IiJC64QtvZds0NzY+k9Ecb7irAgENsj1g9uW81AHM8E E5lIjsRdB0Gtej5BP0NFyxPMNDt4wCSEszMr1C3zyEeege9ufRPiuFEL8A3ILxFjnqT7 cI6uH3zLLDq1k+D9/no8d9Jfezf/M+0zjN7ryxcK3BY7HBtDnu+R2RomuO387hf53OIc G8EUNPsTeBWOgJ72qnlDg3mA5gtjfIJN12tVnXBY/hqNWK6D08AH6JQvIbBlQXFyA6Zw AzPg== X-Gm-Message-State: APjAAAW9oapBh6iJXM/fUluKpfTknACx4otCaqZG0L2uXNUr0jmFhz6h 0KWPfvjvNgg/XBJU0ICB0vuHrkUImSj7CMryUlKw5Q== X-Google-Smtp-Source: APXvYqyZ9A0CS1I8zsGTOD9bwZWO3lYADwL0Xgv+nmfvz7skyl0D1fWZy+MtKEGJ2IAv87Ya4PDUkiZFIL42JMlqhU4= X-Received: by 2002:a6b:6218:: with SMTP id f24mr21433592iog.229.1552493856300; Wed, 13 Mar 2019 09:17:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: William Denniss Date: Wed, 13 Mar 2019 09:17:21 -0700 Message-ID: To: Mike Jones Cc: oauth Content-Type: multipart/alternative; boundary="000000000000d2a2790583fc241f" Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?OAuth_Device_Flow_spec_renamed_to_=E2=80=9C?= =?utf-8?q?OAuth_2=2E0_Device_Authorization_Grant=E2=80=9D?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 16:17:45 -0000 --000000000000d2a2790583fc241f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the recognition Mike, I'm happy to be the editor on this doc. Great write up on the blog! It's been great reading about all the people trying out the draft spec, clearly there is a lot of value to publish. Also thank you everyone who shared their results and feedback as they implemented it. I believe we managed to incorporate your feedback throughout the process, including the recent title change (which was long overdue! I never liked the prior title, despite the fact that I coined it). As the doc will hopefully soon be in the editor queue, the window for changes has likely come to a close. Happy implementing! On Mon, Mar 11, 2019 at 9:45 PM Mike Jones wrote: > I made a blog post about the renaming of the device spec and last-minute > clarifications applied at http://self-issued.info/?p=3D1959 and @selfissu= ed > . Thanks again to William for doing the > heavy lifting! > > > > Hopefully this is the version that gets sent to the RFC Editor=E2=80=A6 > > > > -- Mike > > > --000000000000d2a2790583fc241f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the recognition Mike, I'm happy to be th= e editor on this doc. Great write up on the blog!

It'= ;s been great reading about all the people trying out the draft spec, clear= ly there is a lot of value to publish.

Also thank = you everyone who shared their results and feedback as they implemented it. = I believe we managed to incorporate your feedback throughout the process, i= ncluding the recent title change (which was long overdue! I never liked the= prior title, despite the fact that I coined it). As the doc will hopefully= soon be in the editor queue, the window for changes has likely come to a c= lose. Happy implementing!


--000000000000d2a2790583fc241f-- From nobody Wed Mar 13 10:38:22 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAC6130EF7 for ; Wed, 13 Mar 2019 10:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EMBqszPIAhOP for ; Wed, 13 Mar 2019 10:38:13 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9373A130F02 for ; Wed, 13 Mar 2019 10:38:05 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id v10so2440231iom.8 for ; Wed, 13 Mar 2019 10:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dAhrVciLWeXHX5aXi1XyE8ukmNNVsTI0xI5AdaIAWbE=; b=RuItlrr6l1Ij8u8J+PFV2aWbo2A2fb/SybPEshGade2I+V1B0T1sWUeIISBpjmRJNB ebDgIerISlzL/Zl9jXZSB9h6tKSfxgNvT5nivQ6Q9nOJz8gJeYBW/i/TDC2vZI3+9esK /iN/GdgA0DDRGjvLt5QvhlJbz7eLREGt3IylY/w68MtAmK5uFN04UAZTKguXJoAqvL7n cshk29d6Kh8YRy2XLbOXhEXoBjpLvOCaFHQcHWlSGgbQucq5K/KOYVN2Qp6u+4EjpXq8 zkg9f5gMW7NMt9cfuhyg6xkkjkWq/IuqM++pzOPK3g+Q2e9hvRfylGGv0fXBD2ZSUxTZ BiRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dAhrVciLWeXHX5aXi1XyE8ukmNNVsTI0xI5AdaIAWbE=; b=gvXtRA5JqvZsPdo1CW+h25ARfp5XiCO/pt6E7n5JLfEAUCF9ask/cwHbl1Z6fr5Pg7 qmzL8f5KyuIHYsLZZFqNzeIOVwq4TBo9gyp+aSwtftM4X/GoMPkrsVAdnkhpXAUsXLMt 6Ronu8XIesHl3U2ZxAxEveSlfjO7gKfaRk0SAULSGpRLtxGLZ+CmEmmVhzEQvxCvLTwz QbwRbzrRPwot2CBySQd0PGUBeaiEySkhSOeuo7EU014G1CLUFznpxreQ9W/0jWwXHDR1 +bVUKacMtwr3TxaOGZBuXPNQy6yBFDK7M14zY/j1LEeH5ynEN9afMCgSVBwBLBJIsYLs QYWg== X-Gm-Message-State: APjAAAUkMprCk+AR534PqwN3EbAzCWzL6LUkmnuiWeicoGJSpvx6v+kL Lc5SvBzyE1qMyrKOVU6csjg7gan0GLVvni3ut4EtaNsaI9I= X-Google-Smtp-Source: APXvYqyodlTrDGWjiXcaEGMWvj/Fdu/Iu8cUt1OvyBwMU/nXxr81ChtvbjGP2zWIW5tvr8UVAuiHmshcpHzJ7pEtTzM= X-Received: by 2002:a5d:8489:: with SMTP id t9mr25993003iom.0.1552498683837; Wed, 13 Mar 2019 10:38:03 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Wed, 13 Mar 2019 13:37:51 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000009084ae0583fd447a" Archived-At: Subject: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 17:38:16 -0000 --0000000000009084ae0583fd447a Content-Type: text/plain; charset="UTF-8" All, The following links have our draft agenda for the two sessions: https://datatracker.ietf.org/meeting/104/materials/agenda-104-oauth-sessa-00 https://datatracker.ietf.org/meeting/104/materials/agenda-104-oauth-sessb-00 Please, take a look and let us know if you have any comments. Regards, Rifaat & Hannes --0000000000009084ae0583fd447a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

The following links have our draft= agenda for the two sessions:
 --0000000000009084ae0583fd447a-- From nobody Wed Mar 13 10:46:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1F8131017 for ; Wed, 13 Mar 2019 10:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Q5uDm_0VOBhu for ; Wed, 13 Mar 2019 10:46:05 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148F5130F5B for ; Wed, 13 Mar 2019 10:46:04 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id k21so2428015ior.13 for ; Wed, 13 Mar 2019 10:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:from:date:message-id:subject:to; bh=UWj6toEAzmIqEH0DJpOBjdTFLKUi86nMoNtyzvOmRd8=; b=Z0kupfz2+FyDMxpzBecZmkecXxZWCCIEJHc0sVPKfwhMSWITUB32uOwjQQWhzDKDPi pIFORlqQUlGkXF2taDat/JwaX6xhVYrXnQ+ibYcUMfZmnIVtPZCxdjexpBPqz6tNWKWf gst4JhVciW4h4AekekUz0KCLj/0KDU2ZJOHIdz+TJ5Cj+e58BZo58yjjwi3sIzDxZ4wd vt/lFw+Uc078ywVYQuG9/nB1X+3py531JUuYYIGl2CAjOhW6QPjPxHYKHuozInapBguM pYfW0izUkbpqi3LCM5NTiOJm5lRZp2COvrLVb1K5KdEH6fn/P2azgiR6NBt4Gtl7jEB0 mhnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to; bh=UWj6toEAzmIqEH0DJpOBjdTFLKUi86nMoNtyzvOmRd8=; b=k+a9fAcb+JrzMhZUIWvndzJMVH8a2beRAyiniMJ1A492JzBevR38SMsoMDXIp8+Rx2 bMMcSCWiztntCx5Y7CHgLJ1MPJNgYfT0AInZ1yka2HUO7Qjxkqmeryb6eRh8binVstLC cTTOjT3qVfwSBYMCtwAj+rWzSeHdDZt/TnCYgIiesP0bQD0vyVD5v0MgPmoE7K2Jwqjp +WvE6OAu3K8sGUc5qsud+IKIl5pBIk+7oxs5gYfD8uJBR+1LAtRXkRoVb4iTNOBvw50h j+vV9nkpabHKOu0PgnOjQhpfh5tgV8eXYKZFF9SowtQmd3Aq7/5jb02PN52Rv0gsLqtN 2FJA== X-Gm-Message-State: APjAAAWIAEJ5fkq2vXgB4qxfklSwlsZakig+UeYoBuNPbNBpd0+kjc5G Rb3d4kWl2WktF0ZOoSDl8dwk0JHL7w64uylZr5FotUQpY1A= X-Google-Smtp-Source: APXvYqwEPf2h94jbpudqyXktL1XwHnABUkDXcTdtrxTcpEUhyf8EqLM2C6UuW7QNBM+ZnAZtvyZ2R32w1WpnIcyM6O4= X-Received: by 2002:a5d:8489:: with SMTP id t9mr26017008iom.0.1552499162962; Wed, 13 Mar 2019 10:46:02 -0700 (PDT) MIME-Version: 1.0 References: From: Rifaat Shekh-Yusef Date: Wed, 13 Mar 2019 13:45:52 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000001f607a0583fd61aa" Archived-At: Subject: Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 17:46:07 -0000 --0000000000001f607a0583fd61aa Content-Type: text/plain; charset="UTF-8" Use the following links instead: https://datatracker.ietf.org/doc/agenda-104-oauth-sessa/ https://datatracker.ietf.org/doc/agenda-104-oauth-sessb/ Regards, Rifaat On Wed, Mar 13, 2019 at 1:37 PM Rifaat Shekh-Yusef wrote: > All, > > The following links have our draft agenda for the two sessions: > > > https://datatracker.ietf.org/meeting/104/materials/agenda-104-oauth-sessa-00 > > https://datatracker.ietf.org/meeting/104/materials/agenda-104-oauth-sessb-00 > > Please, take a look and let us know if you have any comments. > > Regards, > Rifaat & Hannes > > --0000000000001f607a0583fd61aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 13, 2019 at 1:37 PM Rifaat Shekh-= Yusef <rifaat.ietf@gmail.com> wrote:
All,

The following links have our draft ag= enda for the two sessions:
--0000000000001f607a0583fd61aa-- From nobody Wed Mar 13 16:21:02 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876281311FE for ; Wed, 13 Mar 2019 16:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 DaiHhJP6pBxz for ; Wed, 13 Mar 2019 16:20:59 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047E11311FC for ; Wed, 13 Mar 2019 16:20:59 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id 188so1695398itb.0 for ; Wed, 13 Mar 2019 16:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jawdvmSilXBMd/dnL31EFmMAKWcWmCWq7jgXswhqtwg=; b=h7D4oAPnCDVxXEFIHUJ8EpOrFffT1RapjKZAkD4y8SfBhTW/lYlj7E2iAXqLHaaYcH gdttvAKWBtKph2Aee5yFj9Sp3nLkxiv5tD0xgZRHVnUptmSSKsb6Ib+8OtOQt6F2UHYT V/dvd/dFPAYcFdp+mmMyn4U5ZE7dCgvBH3uZs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jawdvmSilXBMd/dnL31EFmMAKWcWmCWq7jgXswhqtwg=; b=kqF1T+IN9yaoCisEbhKfzaSXrHq/oarap3HKhHoSADPplnl1qD5oXMUlOXwwBR65tr duf8xUZBSn30TL+8XMMsFv/o/ilZeA1Tid2NHt/B+lbii+Pnnkt5w9u13kHfEObuwo4q Ya1f3qIz1sJDhxjpVyy1A+DV4mQVa9wCPL6V/23Yq4joRnKXjJ3A9MzMLdrBHLrue80o WKrYAH5w27jlQCW99UreoDZXnlDQeRdlF0pe+sohncBIyByb6ZndqTVfH2trNQ0LN7Qk wtzdhOmaPCc6pY7NXEn2HP2ueoyA4IqeXGrRVbLfFIqP81VNQ5PdCs9qugSQqwKZPwZK Caxw== X-Gm-Message-State: APjAAAXO94t2/7o/5prJKw1YUWWkyYs/1vGGTfJFbv20EKZslcd9Y9TV v06sh2qWFH7kSQDlQIDBcZlEFLehCFZexjzxTDKxqTR8AxvLmIMe06xLvspEmlWsQsDnKh569f4 oSyIA0PhnLO17kQ== X-Google-Smtp-Source: APXvYqwDjAPwbeGDKLd9OrKOqnU26y4dFJ6lupPrOKmOJLWha49qT8b8dOv1ry0A0XF6vaP0rniArl39LpRIgbVMjfI= X-Received: by 2002:a24:b90d:: with SMTP id w13mr380008ite.45.1552519258159; Wed, 13 Mar 2019 16:20:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Wed, 13 Mar 2019 17:20:32 -0600 Message-ID: To: Vittorio Bertocci Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000e3d78f0584020e38" Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 23:21:01 -0000 --000000000000e3d78f0584020e38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I kinda said on that call, I understand the ask and I do think it'd be reasonable to mention refresh tokens in the abstract now that the document does describe binding refresh tokens to the client certificate with public clients. I'm struggling to see the fix as pretty easy, however, given the text of the abstract (copied below for ease of reference) and the content and scope of the document. Do you think changing the first sentence to have "certificate-bound access and refresh tokens" is sufficient (and accurate)? Or something more or different? In which case proposed text is always welcome. Abstract This document describes OAuth client authentication and certificate- bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci wrote: > Hi all, > during today's office hours call I pointed out that oauth-mtls-13's abstr= act > only mentions access token, although the spec does provide (some) guidanc= e > on refresh token binding as well.. > Although in the end implementers would do the right thing, given that the= y > have to read the spec in its entirety, having a mention of refresh tokens > in the abstract as well would make it easier for superficial readers to > learn that the spec does address RTs as well. Refresh tokens leakage is o= ne > of the top concerns of the customers I deal with, and those people rarely > read specs from cover to cover: having language in the abstract explicitl= y > calling out RTs might make some conversations easier. > > This is admittedly very minor, but the fix would also be pretty easy, > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000e3d78f0584020e38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I kinda said on that call, I unde= rstand the ask and I do think it'd be reasonable to mention refresh tok= ens in the abstract now that the document does describe binding refresh tok= ens to the client certificate with public clients.

I'm struggling to see the fix as pretty easy, however, given the = text of the abstract (copied below for ease of reference) and the content a= nd scope of the document.

Do you think changi= ng the first sentence to have "certificate-bound access and refresh to= kens" is sufficient (and accurate)?

Or s= omething more or different? In which case proposed text is always welcome.<= br>

Abstract

   This document describes OAuth client authentication and certificate-
   bound access tokens using mutual Transport Layer Security (TLS)
   authentication with X.509 certificates.  OAuth clients are provided a
   mechanism for authentication to the authorization server using mutual
   TLS, based on either self-signed certificates or public key
   infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.

On Mon, Mar 11, 2019 at 4:= 06 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wro= te:
Hi all,
during today's office hours call I pointed out that=C2= =A0oauth-mtls-13= 9;s=C2=A0abstract only mentions access token, although the spec does= provide (some) guidance on=C2=A0 refresh token binding as well..=C2=A0
Although in the end implementers would do the right thing, given tha= t they have to read the spec in its entirety, having a mention of refresh t= okens in the abstract as well would make it easier for superficial readers = to learn that the spec does address RTs as well. Refresh tokens leakage is = one of the top concerns of the customers I deal with, and those people rare= ly read specs from cover to cover: having language in the abstract explicit= ly calling out RTs might make some conversations easier.

This is admittedly very minor, but the fix would also be pretty easy= ,=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000e3d78f0584020e38-- From nobody Thu Mar 14 00:08:06 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F0C12799B for ; Thu, 14 Mar 2019 00:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qt9E6c8NLNjz for ; Thu, 14 Mar 2019 00:08:02 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A1D1200D7 for ; Thu, 14 Mar 2019 00:08:02 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id b3so4192267otp.4 for ; Thu, 14 Mar 2019 00:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0bEdmc68hc0Hiu4tHLj+lNppr7iTxIQNJHYlS7tgsdI=; b=MvWIyWoIHCs8MQ22aNWZZG18ABr1IMU9gccRYtrhMUucz/aTxetnGt+AIfm/RfpzUK QuIcJScLIb8RNHPZka+9nTWr8HqhTWEHzO7lq8dQu9+XgPDhI351MCrAJc8IfqYoh3qL aYrcXK8hPr0zulf03HaX0OuPCwpJhdaMi17394+nf4n3wHiQyppFWzLdfLsoTaL4MoRi ETNFWAbwpH2Q4IxxpvqOhzkVCP+Ug4yA/ajMJndQX6kCvaXwU/mdQ5sBpfnteQaQ55aL NWBAM8Uq5tuUmknt2Tb9V6vemTh/oZALAmQtIWU/iFHSoHytdWXDYvPl1OPRmcVLfyiv nd3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0bEdmc68hc0Hiu4tHLj+lNppr7iTxIQNJHYlS7tgsdI=; b=Ck7KMEiVADpSJFKWL24IGwd27F4r2Bypblt5gZ9Yj8nX00UafFg5AxAgOLlPDqkT6D 28pIZbMOZdntLLmOSBhReoQdwUCgjgL6HMYvXuAyI4oXdEPuWqQTxalhHcaLx7/HuIiP mvezIqRMkjx4illk8m0FJz1l8eJlQRNyZG7NLIItYrfcPB7z3KIAcOLRffAxCvMiderP bioEAULFO+Zz7a1Oe+W54dOR7o/aWudeyJZaWlEu7i7d/tk0+5mNlpglF96SroYlW4WD +QGR3sG5IlqXOcIosGzXB/F+/7DXGlQkqCGJ1nB+1nB3WoGjT7WmIeqd7y8Mtll68bFM sjvw== X-Gm-Message-State: APjAAAVcrUMQSBuL3lgaztyo9310f2YWPLfUuCw+UJOhu26CzK6tszh5 63LV5KokQTx3SgBoqsTtV+WFRkCkgVv7gJ7gBQ== X-Google-Smtp-Source: APXvYqzW8m1H2o6dG7N9H+se7fSEzh0BQOs4nCVFZCe6rCdhGV0A7/mFjMvtZ8jvJNG8t4nHct6l9JbVShotxQb7dm4= X-Received: by 2002:a9d:7594:: with SMTP id s20mr31257802otk.112.1552547281083; Thu, 14 Mar 2019 00:08:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Thu, 14 Mar 2019 08:07:50 +0100 Message-ID: To: Brian Campbell Cc: Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000002fa3f505840895cd" Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 07:08:05 -0000 --0000000000002fa3f505840895cd Content-Type: text/plain; charset="UTF-8" Even before refresh tokens were mentioned in draft 13 i was about to implement this binding in nodejs oidc-provider, the thing i struggled with and ultimately didn't do this was 1) if the refresh token is bound to a specific cert then this cert rotation is out of the question 2) if having the RT somehow covered is needed, isn't MTLS client auth already the right thing to do? Especially given it supports cert rotation Now the normative language is SHOULD therefore disallowing cert rotation. Or am I missing something? S pozdravem, *Filip Skokan* On Thu, 14 Mar 2019 at 00:21, Brian Campbell wrote: > As I kinda said on that call, I understand the ask and I do think it'd be > reasonable to mention refresh tokens in the abstract now that the document > does describe binding refresh tokens to the client certificate with public > clients. > > I'm struggling to see the fix as pretty easy, however, given the text of > the abstract (copied below for ease of reference) and the content and scope > of the document. > > Do you think changing the first sentence to have "certificate-bound access > and refresh tokens" is sufficient (and accurate)? > > Or something more or different? In which case proposed text is always > welcome. > > Abstract > > This document describes OAuth client authentication and certificate- > bound access tokens using mutual Transport Layer Security (TLS) > authentication with X.509 certificates. OAuth clients are provided a > mechanism for authentication to the authorization server using mutual > TLS, based on either self-signed certificates or public key > infrastructure (PKI). OAuth authorization servers are provided a > mechanism for binding access tokens to a client's mutual TLS > certificate, and OAuth protected resources are provided a method for > ensuring that such an access token presented to it was issued to the > client presenting the token. > > > On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > >> Hi all, >> during today's office hours call I pointed out that oauth-mtls-13's abstract >> only mentions access token, although the spec does provide (some) guidance >> on refresh token binding as well.. >> Although in the end implementers would do the right thing, given that >> they have to read the spec in its entirety, having a mention of refresh >> tokens in the abstract as well would make it easier for superficial readers >> to learn that the spec does address RTs as well. Refresh tokens leakage is >> one of the top concerns of the customers I deal with, and those people >> rarely read specs from cover to cover: having language in the abstract >> explicitly calling out RTs might make some conversations easier. >> >> This is admittedly very minor, but the fix would also be pretty easy, >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000002fa3f505840895cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Even before refresh tokens were mentioned in draft 13= i was about to implement this binding in nodejs oidc-provider,

the thing i struggled with and ultimately didn't do t= his was

1) if the refresh token is bound to a spec= ific cert then this cert rotation is out of the question
2) if ha= ving the RT somehow covered is needed, isn't MTLS client auth already t= he right thing to do? Especially given it supports cert rotation
=
Now the normative language is SHOULD therefore disallowing c= ert rotation. Or am I missing=C2=A0something?

<= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">S pozdravem,
Filip Skokan


On Thu, 14 Mar 2019 = at 00:21, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
As I kinda said on that call, I understand the ask and I do= think it'd be reasonable to mention refresh tokens in the abstract now= that the document does describe binding refresh tokens to the client certi= ficate with public clients.

I'm strugglin= g to see the fix as pretty easy, however, given the text of the abstract (c= opied below for ease of reference) and the content and scope of the documen= t.

Do you think changing the first sentence t= o have "certificate-bound access and refresh tokens" is sufficien= t (and accurate)?

Or something more or differ= ent? In which case proposed text is always welcome.

Abstract

   This document describes OAuth client authentication and certificate-
   bound access tokens using mutual Transport Layer Security (TLS)
   authentication with X.509 certificates.  OAuth clients are provided a
   mechanism for authentication to the authorization server using mutual
   TLS, based on either self-signed certificates or public key
   infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.

On Mon, Mar 11, 2019 at 4:= 06 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wro= te:
Hi all,
during today's office hours call I pointed out that=C2= =A0oauth-mtls-13= 9;s=C2=A0abstract only mentions access token, although the spec does= provide (some) guidance on=C2=A0 refresh token binding as well..=C2=A0
Although in the end implementers would do the right thing, given tha= t they have to read the spec in its entirety, having a mention of refresh t= okens in the abstract as well would make it easier for superficial readers = to learn that the spec does address RTs as well. Refresh tokens leakage is = one of the top concerns of the customers I deal with, and those people rare= ly read specs from cover to cover: having language in the abstract explicit= ly calling out RTs might make some conversations easier.

This is admittedly very minor, but the fix would also be pretty easy= ,=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000002fa3f505840895cd-- From nobody Thu Mar 14 01:09:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6DB1200D7 for ; Thu, 14 Mar 2019 01:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hTLB13Ny6Glj for ; Thu, 14 Mar 2019 01:09:49 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5E11277C9 for ; Thu, 14 Mar 2019 01:09:48 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id k8so3672733oik.8 for ; Thu, 14 Mar 2019 01:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d8d1eRMEpr6Erwi3hFfM/7w0OvHuCJGDjQlXsT/AJIU=; b=moojXz+WJgLbFlb2raq3nhnmWxTOGo2Gvhy78YfIE9pvot6Q+Dey2VItHshowgfo8G otHDaU60hFMRw/tzFeGfQ3UXqCqiaxkfeWqbg2LG/0pdX54uE1Z1HHVltDM0t2oJvEn8 YCX0nCHEJ/MtXaqpo+0zmKhKgGfP+4GDKH/iD9S0JKdC9jOzh/qqXQBPhteZ0j9tGtGv iuREPXoJ1+iQBcoBu0+IoQlpNFulgwuAfMbcwNQsdFej4Ok4M3YX7JeXjBD3zjl+elFN 8RpSw4ePWoc+EfyeZ1B7Hekj1q7LN8xGyrvduBC0Kb4RB6VTU90UePdLLBpF47IpGFDV rOJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d8d1eRMEpr6Erwi3hFfM/7w0OvHuCJGDjQlXsT/AJIU=; b=okyxZHbrwQRImuDwsCHbnolUA48+Wy7XkqmWZc4kmnsrY1NNy7ICAIbhJTYKqoMAPo 2j/bxiW7BSZRg/DJg/47XCtikg2/VGLPNSUGcxKDGMbakD63yFDdND+2W9D7ACUp0Kk8 5Dn/hZ/2jIVDYDl70IMaJq302Pyoj7ddfxqzBd+vUbhrybA8jPNwRSubhjkdyW9g4VbN VRxPTp+MqnzxatX1wTq40ciU9bdQ9zRuN20VHSJBTClALdtDAkkTVsdR4kuoC5fJEngR RJSRAt5FcktEtW0LNrX/Wzoz+i7G7Kw93tqE++TEHH6XC5UuQN72mXxdqWN2kR3Eug2H V1gw== X-Gm-Message-State: APjAAAUJlpp2wAbCqwo9ohaFT3bsMziggp59R3dgauIf9rgKDnZmGt92 j0a0n+GgbBHt3aDe1Jwdvm3UmlZv0JGC3QPGpw== X-Google-Smtp-Source: APXvYqzWA7MvzYZQPcBPtyQWfvBBrRImvzzgo5V7Tz8BpNROJscjnRQdAH7W2VSHy6H8XBMZQphWNuuaAmMvj2RPdTM= X-Received: by 2002:aca:b4d6:: with SMTP id d205mr1297955oif.13.1552550988184; Thu, 14 Mar 2019 01:09:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Thu, 14 Mar 2019 09:09:37 +0100 Message-ID: To: Brian Campbell Cc: Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000002585d205840972a8" Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 08:09:52 -0000 --0000000000002585d205840972a8 Content-Type: text/plain; charset="UTF-8" Point being that since the refresh token is only usable on the IdP then mtls client auth already covers this, and since RTs are long-lasting, it does this better because cert rotation is possible for both mtls methods. S pozdravem, *Filip Skokan* On Thu, 14 Mar 2019 at 08:07, Filip Skokan wrote: > Even before refresh tokens were mentioned in draft 13 i was about to > implement this binding in nodejs oidc-provider, > > the thing i struggled with and ultimately didn't do this was > > 1) if the refresh token is bound to a specific cert then this cert > rotation is out of the question > 2) if having the RT somehow covered is needed, isn't MTLS client auth > already the right thing to do? Especially given it supports cert rotation > > Now the normative language is SHOULD therefore disallowing cert rotation. > Or am I missing something? > > S pozdravem, > *Filip Skokan* > > > On Thu, 14 Mar 2019 at 00:21, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> As I kinda said on that call, I understand the ask and I do think it'd be >> reasonable to mention refresh tokens in the abstract now that the document >> does describe binding refresh tokens to the client certificate with public >> clients. >> >> I'm struggling to see the fix as pretty easy, however, given the text of >> the abstract (copied below for ease of reference) and the content and scope >> of the document. >> >> Do you think changing the first sentence to have "certificate-bound >> access and refresh tokens" is sufficient (and accurate)? >> >> Or something more or different? In which case proposed text is always >> welcome. >> >> Abstract >> >> This document describes OAuth client authentication and certificate- >> bound access tokens using mutual Transport Layer Security (TLS) >> authentication with X.509 certificates. OAuth clients are provided a >> mechanism for authentication to the authorization server using mutual >> TLS, based on either self-signed certificates or public key >> infrastructure (PKI). OAuth authorization servers are provided a >> mechanism for binding access tokens to a client's mutual TLS >> certificate, and OAuth protected resources are provided a method for >> ensuring that such an access token presented to it was issued to the >> client presenting the token. >> >> >> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci > 40auth0.com@dmarc.ietf.org> wrote: >> >>> Hi all, >>> during today's office hours call I pointed out that oauth-mtls-13's abstract >>> only mentions access token, although the spec does provide (some) guidance >>> on refresh token binding as well.. >>> Although in the end implementers would do the right thing, given that >>> they have to read the spec in its entirety, having a mention of refresh >>> tokens in the abstract as well would make it easier for superficial readers >>> to learn that the spec does address RTs as well. Refresh tokens leakage is >>> one of the top concerns of the customers I deal with, and those people >>> rarely read specs from cover to cover: having language in the abstract >>> explicitly calling out RTs might make some conversations easier. >>> >>> This is admittedly very minor, but the fix would also be pretty easy, >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited.. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.*_______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --0000000000002585d205840972a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Point being that since the refresh token is only usable on= the IdP then mtls client auth already covers this, and since RTs are long-= lasting, it does this better because cert rotation is possible for both mtl= s methods.

S pozdravem,
Filip Skokan


On Thu, 14 Mar 2019 at 08:07, Filip Skokan <panva.ip@gmail.com> wrote:
Ev= en before refresh tokens were mentioned in draft 13 i was about to implemen= t this binding in nodejs oidc-provider,

the th= ing i struggled with and ultimately didn't do this was

1) if the refresh token is bound to a specific cert then this cert= rotation is out of the question
2) if having the RT somehow cove= red is needed, isn't MTLS client auth already the right thing to do? Es= pecially given it supports cert rotation

Now the n= ormative language is SHOULD therefore disallowing cert rotation. Or am I mi= ssing=C2=A0something?

S pozdravem,
Filip Skok= an


On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcam= pbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
As I kinda said on that call, I understand the ask and I do think it'd= be reasonable to mention refresh tokens in the abstract now that the docum= ent does describe binding refresh tokens to the client certificate with pub= lic clients.

I'm struggling to see the fi= x as pretty easy, however, given the text of the abstract (copied below for= ease of reference) and the content and scope of the document.

Do you think changing the first sentence to have "ce= rtificate-bound access and refresh tokens" is sufficient (and accurate= )?

Or something more or different? In which c= ase proposed text is always welcome.

Abst=
ract

   This document describes OAuth client authentication and certificate-
   bound access tokens using mutual Transport Layer Security (TLS)
   authentication with X.509 certificates.  OAuth clients are provided a
   mechanism for authentication to the authorization server using mutual
   TLS, based on either self-signed certificates or public key
   infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.

On Mon, Mar 11, 2019 at 4:= 06 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wro= te:
Hi all,
during today's office hours call I pointed out that=C2= =A0oauth-mtls-13= 9;s=C2=A0abstract only mentions access token, although the spec does= provide (some) guidance on=C2=A0 refresh token binding as well..=C2=A0
Although in the end implementers would do the right thing, given tha= t they have to read the spec in its entirety, having a mention of refresh t= okens in the abstract as well would make it easier for superficial readers = to learn that the spec does address RTs as well. Refresh tokens leakage is = one of the top concerns of the customers I deal with, and those people rare= ly read specs from cover to cover: having language in the abstract explicit= ly calling out RTs might make some conversations easier.

This is admittedly very minor, but the fix would also be pretty easy= ,=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000002585d205840972a8-- From nobody Thu Mar 14 01:17:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D08127988 for ; Thu, 14 Mar 2019 01:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thales.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 D55e2-w8mhBL for ; Thu, 14 Mar 2019 01:17:12 -0700 (PDT) Received: from mail.thales.no (mail.thales.no [213.52.79.195]) (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 3EB771200D7 for ; Thu, 14 Mar 2019 01:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thales.no; i=@thales.no; q=dns/txt; s=s1; t=1552551433; x=1584087433; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fHuzUkYTQSbLnSOWbTLdpGFhTfntcWPGNmmeziFvdiA=; b=UdBGahLclOsq8t5ujCfYWm65cTrn13fmLORCmeuAsguBQN5BBHrzAhi5 nKFKaFw+mwhOzG41d13YTzG3ioxcVvuLyCUgT5nN6PFa6NVBMCgqA17W6 NoY0vtmGNJReWcsXcGvUvLG8Xx20BPsXvZZjpfCVrH15t8CkH75F9yu7a QCeiFeQOJrbzLLl2ba6qRmnWoXvQdMgfgfwd0qgphx0WmRx1bCXJAAPi6 Soe1taxeHQGWOsZr4y3IQQt9Y5hzEkhDVuDG17DnaLfrj9BOCJ6mofA4h UuQ9juNQsuaSlaMnwqgVunLQh3GxcVe6jJF9HVD4Nv6r5GxMJ7bLqT1Tx Q==; X-IronPort-AV: E=Sophos;i="5.58,477,1544482800"; d="scan'208,217";a="109598" x-originating-ip: [213.52.79.195] From: Lars Wilhelmsen To: Rifaat Shekh-Yusef , oauth Thread-Topic: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings Thread-Index: AQHU2cOkD0I21kLHkECOBLC3GR0no6YJ1dvEgADzD3A= Date: Thu, 14 Mar 2019 08:17:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_e5b87758159e42688d371d0b7cf37cb0Thalesno_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 08:17:15 -0000 --_000_e5b87758159e42688d371d0b7cf37cb0Thalesno_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFyZSB0aGVzZSBzZXNzaW9ucyByZWNvcmRlZCAvIGF2YWlsYWJsZSB0byBmb2xsb3cg b25saW5lPw0KDQpSZWdhcmRzLA0KICAtLWxhcnN3DQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUmlmYWF0IFNoZWtoLVl1c2VmDQpTZW50OiBvbnNk YWcgMTMuIG1hcnMgMjAxOSAxODo0Ng0KVG86IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIERyYWZ0IEFnZW5kYSBmb3IgSUVURjEwNCBPQXV0aCBXRyBtZWV0 aW5ncw0KDQpVc2UgdGhlIGZvbGxvd2luZyBsaW5rcyBpbnN0ZWFkOg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvYWdlbmRhLTEwNC1vYXV0aC1zZXNzYS8NCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2FnZW5kYS0xMDQtb2F1dGgtc2Vzc2IvDQoNClJlZ2FyZHMsDQog UmlmYWF0DQoNCg0KT24gV2VkLCBNYXIgMTMsIDIwMTkgYXQgMTozNyBQTSBSaWZhYXQgU2hla2gt WXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29t Pj4gd3JvdGU6DQpBbGwsDQoNClRoZSBmb2xsb3dpbmcgbGlua3MgaGF2ZSBvdXIgZHJhZnQgYWdl bmRhIGZvciB0aGUgdHdvIHNlc3Npb25zOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvMTA0L21hdGVyaWFscy9hZ2VuZGEtMTA0LW9hdXRoLXNlc3NhLTAwDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9hZ2VuZGEtMTA0LW9h dXRoLXNlc3NiLTAwDQoNClBsZWFzZSwgdGFrZSBhIGxvb2sgYW5kIGxldCB1cyBrbm93IGlmIHlv dSBoYXZlIGFueSBjb21tZW50cy4NCg0KUmVnYXJkcywNCiBSaWZhYXQgJiBIYW5uZXMNCg0K --_000_e5b87758159e42688d371d0b7cf37cb0Thalesno_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44 NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iTk8tQk9LIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXJlIHRoZXNlIHNl c3Npb25zIHJlY29yZGVkIC8gYXZhaWxhYmxlIHRvIGZvbGxvdyBvbmxpbmU/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj4mbmJzcDsgLS1sYXJzdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCAmbHQ7b2F1dGgt Ym91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmlmYWF0IFNoZWtoLVl1 c2VmPGJyPg0KPGI+U2VudDo8L2I+IG9uc2RhZyAxMy4gbWFycyAyMDE5IDE4OjQ2PGJyPg0KPGI+ VG86PC9iPiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbT0FVVEgtV0ddIERyYWZ0IEFnZW5kYSBmb3IgSUVURjEwNCBPQXV0aCBXRyBtZWV0aW5n czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlVzZSB0aGUgZm9sbG93aW5nIGxpbmtzIGluc3RlYWQ6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvYWdlbmRhLTEwNC1vYXV0aC1zZXNzYS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2FnZW5kYS0xMDQtb2F1dGgtc2Vzc2EvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvYWdlbmRhLTEwNC1vYXV0aC1zZXNzYi8iPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2FnZW5kYS0xMDQtb2F1dGgtc2Vzc2IvPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Umlm YWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXIgMTMsIDIwMTkgYXQgMTozNyBQ TSBSaWZhYXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFp bC5jb20iPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmb2xsb3dp bmcgbGlua3MgaGF2ZSBvdXIgZHJhZnQgYWdlbmRhIGZvciB0aGUgdHdvIHNlc3Npb25zOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNC9tYXRlcmlhbHMvYWdlbmRhLTEwNC1v YXV0aC1zZXNzYS0wMCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNC9t YXRlcmlhbHMvYWdlbmRhLTEwNC1vYXV0aC1zZXNzYS0wMDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9hZ2VuZGEtMTA0LW9h dXRoLXNlc3NiLTAwIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21h dGVyaWFscy9hZ2VuZGEtMTA0LW9hdXRoLXNlc3NiLTAwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSwgdGFrZSBhIGxvb2sgYW5kIGxldCB1 cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdCAmYW1wOyBIYW5u ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e5b87758159e42688d371d0b7cf37cb0Thalesno_-- From nobody Thu Mar 14 01:26:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045A51277DB for ; Thu, 14 Mar 2019 01:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com 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 dl8eKo2u8Ahu for ; Thu, 14 Mar 2019 01:26:18 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8BC127988 for ; Thu, 14 Mar 2019 01:26:18 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id f65so1902061wma.2 for ; Thu, 14 Mar 2019 01:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ex3cIXaBeUe/4NCatzcvpdHPqe1wG683DZfnDR0wl3o=; b=kQLTbeFh0BsLtnuNe+kn9ouJxwpUdarQQbtdUUOwmSMKlmh6saj22V2iJ8T6o1Bvd2 JZFZ1kh6/RvlRYDjQqIUWe0hCyOXHqct1PLDw8RNlh7RjBMxNdpHf2Golqz/TPNirSE+ kYr4zqriyEtW52YT5KRGKCnbhwxuC7lG/JdxI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ex3cIXaBeUe/4NCatzcvpdHPqe1wG683DZfnDR0wl3o=; b=oN8tWA68bGmVyUYBAfoORuixkxe45p4UP8j56rWBUXA2cyoDjuvBwxCFaW9oOGmz2h U2gsjN385KdST1KkHAx1r98dLOiSk/AEjEGpZCOZ9LI0cyC10hsKX4hAFHwxpDRUAjVC tifJxxX7rPeCLlqjwRVsFUxlhqYmwr0v1VkyAAGJ1Lar1KdAC7q7IkEF6z3CcUNq5rRt gAFZcyD1+05s210OvwuDny3yE7C6EirxZD6/08aNj6R9HeaVlp5VPkjd1w+fQxeJAlCR ua+mnPmv1g7nzkOq0Si588M5BV7fye8vnb+3r+bjejHzA8qngxjAE6yV4ApTCoenKNS/ XdZA== X-Gm-Message-State: APjAAAXTSE7SvaQ+pA8uuc35rIA/pGUHxCCW1yPcX4QS+9+PmzNhwgDp wqyvW+3Z4nOBicmam9MquhObUp2VDoe17PEumPOsSsYFQ3SFvVQjHnoxfHtr9K+KQPA5P7at43s 6RLuaY1XJyLZeVfQLY0OKabpqtclLx9jjgxH4XTWiW55q0qBx41Ve4K0MJBq0taM= X-Google-Smtp-Source: APXvYqxmiS5GsCyto7FfCibaH3rewe284e3macUAfe+dwpvcqoDDE0b2NdR2ED3CO8t3E6r19EY4Tg== X-Received: by 2002:a1c:2743:: with SMTP id n64mr1660581wmn.143.1552551976151; Thu, 14 Mar 2019 01:26:16 -0700 (PDT) Received: from ?IPv6:2a01:4c8:1d:1140:f82b:8d56:e0e8:2f0a? ([2a01:4c8:1d:1140:f82b:8d56:e0e8:2f0a]) by smtp.gmail.com with ESMTPSA id b8sm5220983wrx.33.2019.03.14.01.26.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 01:26:15 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-8D5E6004-5CF4-4874-AD9F-B401A3C3D902 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Thu, 14 Mar 2019 08:26:14 +0000 Cc: Brian Campbell , IETF oauth WG Content-Transfer-Encoding: 7bit Message-Id: <5428A862-D273-42F0-8E7A-9D3FFF191F0E@forgerock.com> References: To: Filip Skokan Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 08:26:22 -0000 --Apple-Mail-8D5E6004-5CF4-4874-AD9F-B401A3C3D902 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Right - this is what we have implemented. No support for certificate-bound r= efresh tokens, the client can be configured to require TLS cert client authe= ntication instead.=20 Neil > On 14 Mar 2019, at 08:09, Filip Skokan wrote: >=20 > Point being that since the refresh token is only usable on the IdP then mt= ls client auth already covers this, and since RTs are long-lasting, it does t= his better because cert rotation is possible for both mtls methods. >=20 > S pozdravem, > Filip Skokan >=20 >=20 >> On Thu, 14 Mar 2019 at 08:07, Filip Skokan wrote: >> Even before refresh tokens were mentioned in draft 13 i was about to impl= ement this binding in nodejs oidc-provider, >>=20 >> the thing i struggled with and ultimately didn't do this was >>=20 >> 1) if the refresh token is bound to a specific cert then this cert rotati= on is out of the question >> 2) if having the RT somehow covered is needed, isn't MTLS client auth alr= eady the right thing to do? Especially given it supports cert rotation >>=20 >> Now the normative language is SHOULD therefore disallowing cert rotation.= Or am I missing something? >>=20 >> S pozdravem, >> Filip Skokan >>=20 >>=20 >>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell wrote: >>> As I kinda said on that call, I understand the ask and I do think it'd b= e reasonable to mention refresh tokens in the abstract now that the document= does describe binding refresh tokens to the client certificate with public c= lients.=20 >>>=20 >>> I'm struggling to see the fix as pretty easy, however, given the text of= the abstract (copied below for ease of reference) and the content and scope= of the document.=20 >>>=20 >>> Do you think changing the first sentence to have "certificate-bound acce= ss and refresh tokens" is sufficient (and accurate)?=20 >>>=20 >>> Or something more or different? In which case proposed text is always we= lcome. >>>=20 >>> Abstract >>>=20 >>> This document describes OAuth client authentication and certificate- >>> bound access tokens using mutual Transport Layer Security (TLS) >>> authentication with X.509 certificates. OAuth clients are provided a= >>> mechanism for authentication to the authorization server using mutual= >>> TLS, based on either self-signed certificates or public key >>> infrastructure (PKI). OAuth authorization servers are provided a >>> mechanism for binding access tokens to a client's mutual TLS >>> certificate, and OAuth protected resources are provided a method for >>> ensuring that such an access token presented to it was issued to the >>> client presenting the token. >>>=20 >>>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci wrote: >>>> Hi all, >>>> during today's office hours call I pointed out that oauth-mtls-13's abs= tract only mentions access token, although the spec does provide (some) guid= ance on refresh token binding as well..=20 >>>> Although in the end implementers would do the right thing, given that t= hey have to read the spec in its entirety, having a mention of refresh token= s in the abstract as well would make it easier for superficial readers to le= arn that the spec does address RTs as well. Refresh tokens leakage is one of= the top concerns of the customers I deal with, and those people rarely read= specs from cover to cover: having language in the abstract explicitly calli= ng out RTs might make some conversations easier. >>>>=20 >>>> This is admittedly very minor, but the fix would also be pretty easy,=20= >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileg= ed material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited... If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you._______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-8D5E6004-5CF4-4874-AD9F-B401A3C3D902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Rig= ht - this is what we have implemented. No support for certificate-bound refr= esh tokens, the client can be configured to require TLS cert client authenti= cation instead. 

Neil<= /div>

On 14 Mar 2019, at 08:09, Filip Skokan <panva.ip@gmail.com> wrote:

Point being th= at since the refresh token is only usable on the IdP then mtls client auth a= lready covers this, and since RTs are long-lasting, it does this better beca= use cert rotation is possible for both mtls methods.

<= div>
S pozdravem,
Filip Skokan


On Thu, 14 Mar= 2019 at 08:07, Filip Skokan <panva= .ip@gmail.com> wrote:
Even before refresh tokens were mentioned i= n draft 13 i was about to implement this binding in nodejs oidc-provider,

the thing i struggled with and ultimately didn't d= o this was

1) if the refresh token is bound to a sp= ecific cert then this cert rotation is out of the question
2) if h= aving the RT somehow covered is needed, isn't MTLS client auth already the r= ight thing to do? Especially given it supports cert rotation

<= /div>
Now the normative language is SHOULD therefore disallowing cert ro= tation. Or am I missing something?

S pozdravem,<= br>Filip Skokan


<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, 14 Mar 2019 at 00:21, Brian Cam= pbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex">
As I kinda said on that call, I understand the ask and I do think= it'd be reasonable to mention refresh tokens in the abstract now that the d= ocument does describe binding refresh tokens to the client certificate with p= ublic clients.

I'm struggling to see the fix a= s pretty easy, however, given the text of the abstract (copied below for eas= e of reference) and the content and scope of the document.
Do you think changing the first sentence to have "certificate-b= ound access and refresh tokens" is sufficient (and accurate)?

Or something more or different? In which case proposed text i= s always welcome.

Abstract

   This document describes OAuth client authentication and certificate-
   bound access tokens using mutual Transport Layer Security (TLS)
   authentication with X.509 certificates.  OAuth clients are provided a
   mechanism for authentication to the authorization server using mutual
   TLS, based on either self-signed certificates or public key
   infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.

On Mon, Mar 11, 2019 at 4:06= PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:<= br>
H= i all,
during today's office hours call I pointed out that oauth-mtls-13's a= bstract only mentions access token, although the spec does provide (some) gu= idance on  refresh token binding as well.. 
Although in t= he end implementers would do the right thing, given that they have to read t= he spec in its entirety, having a mention of refresh tokens in the abstract a= s well would make it easier for superficial readers to learn that the spec d= oes address RTs as well. Refresh tokens leakage is one of the top concerns o= f the customers I deal with, and those people rarely read specs from cover t= o cover: having language in the abstract explicitly calling out RTs might ma= ke some conversations easier.

This is admittedly ve= ry minor, but the fix would also be pretty easy, 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited...  I= f you have received this communication in error, please notify the sender im= mediately by e-mail and delete the message and any file attachments from you= r computer. Thank you.____________________________________= ___________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
________= _______________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.= ietf.org/mailman/listinfo/oauth
= --Apple-Mail-8D5E6004-5CF4-4874-AD9F-B401A3C3D902-- From nobody Thu Mar 14 05:29:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B4C1277D7 for ; Thu, 14 Mar 2019 05:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 jTaw5CqzzcES for ; Thu, 14 Mar 2019 05:29:10 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D47912F1AB for ; Thu, 14 Mar 2019 05:29:10 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id z124so4533662itc.2 for ; Thu, 14 Mar 2019 05:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3qn3AuHtvbe15hhEGScLqgBE5ZVXgPFgkys5H5o6Wvk=; b=SjIAz/im1F9BcZxfy16J2oCUGUaGpMtGpR9LVjTwG2HZTJksw1FbQsZ8XEGmJ6ZerS 4GPoeQsqzeORYx4BEPEUUIZLpKjlmZi8mQbOpE4cmBtmQTeRgjobP+r8uM4gpBD0SaVh RwJGsoIQhy9gOambbFdY0vGU4kK4iKN7nwLzE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3qn3AuHtvbe15hhEGScLqgBE5ZVXgPFgkys5H5o6Wvk=; b=iTbz+Vjt1e6AuUtlzy0TqdOyK7XgNE/Rx/ax9ns43D7OYqVcIGv9g73/tMyOtmZiL3 qryXegNSkUXvrLQXixCpgNIjQUjkkt9GTYTq08JiqvC5VNGTQukjPSQhkrikhzow+T5M 3bpM5PvE7LcUeRXo7lMIJBl8U7EtID/JsDzZ3GDrwOrUDaMqpZHiflJjxaCeUbH/Uvh5 HwNAOkk3VXQWHFv/ozv5JEzEmXfIdmj4x3Lwh3xa6fmKsyYQDk7rYkSwL4rXZbJ3bSXv RIcQ9rTqHMH4UQiu0aBYgWWUxsOGFuYWdC7qqpmD1xME6HqkFQLhI4qWsp9NPN2ddrqY 4YNg== X-Gm-Message-State: APjAAAW9M6bLF/d3SR1dqAkWn6iDvWKrMoT3iB4OT91XXPHjW5MNnCs9 +kSlCSXvUxfGErI2t0mKYHk+aTXL4TP0Dj5kXOrJ1Uv/49GhS8GtHvFYQ5Ij30IjDZbNr5Bn9z6 HT3PFbvZlMtGT7A== X-Google-Smtp-Source: APXvYqyWtrVIG9ctW3eb58iibQoR37/MktchRzLMMufoF8UPEDUpcDjth9xUO2bfbXkueftT2d/lZXSfS2a+aa+wgmY= X-Received: by 2002:a24:b501:: with SMTP id v1mr1796048ite.174.1552566549261; Thu, 14 Mar 2019 05:29:09 -0700 (PDT) MIME-Version: 1.0 References: <5428A862-D273-42F0-8E7A-9D3FFF191F0E@forgerock.com> In-Reply-To: <5428A862-D273-42F0-8E7A-9D3FFF191F0E@forgerock.com> From: Brian Campbell Date: Thu, 14 Mar 2019 06:28:42 -0600 Message-ID: To: Neil Madden Cc: Filip Skokan , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000a8d07505840d1159" Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 12:29:14 -0000 --000000000000a8d07505840d1159 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, so regular old RFC 6749 OAuth requires that a refresh token be bound to the client to whom it was issued. And that confidential clients (those having established authn credentials) authenticate to the AS when presenting a refresh token. Thus, for both MTLS methods of OAuth client authentication, refresh tokens are indirectly certificate-bound through their binding to a client and its credentials (and the client rotating its cert doesn't invalidate the refresh token). What was added in the -13 revision of the draft (in a new section https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a brief description of certificate binding refresh tokens for public clients. The ask from Vittorio was a mention of refresh tokens in abstract. Which seems reasonable. But the proper wording to succinctly and accurately convey the aforementioned subtleties is proving difficult for me. On Thu, Mar 14, 2019 at 2:26 AM Neil Madden wrote: > Right - this is what we have implemented. No support for certificate-boun= d > refresh tokens, the client can be configured to require TLS cert client > authentication instead. > > Neil > > On 14 Mar 2019, at 08:09, Filip Skokan wrote: > > Point being that since the refresh token is only usable on the IdP then > mtls client auth already covers this, and since RTs are long-lasting, it > does this better because cert rotation is possible for both mtls methods. > > S pozdravem, > *Filip Skokan* > > > On Thu, 14 Mar 2019 at 08:07, Filip Skokan > wrote: > >> Even before refresh tokens were mentioned in draft 13 i was about to >> implement this binding in nodejs oidc-provider, >> >> the thing i struggled with and ultimately didn't do this was >> >> 1) if the refresh token is bound to a specific cert then this cert >> rotation is out of the question >> 2) if having the RT somehow covered is needed, isn't MTLS client auth >> already the right thing to do? Especially given it supports cert rotatio= n >> >> Now the normative language is SHOULD therefore disallowing cert rotation= . >> Or am I missing something? >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Thu, 14 Mar 2019 at 00:21, Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >>> As I kinda said on that call, I understand the ask and I do think it'd >>> be reasonable to mention refresh tokens in the abstract now that the >>> document does describe binding refresh tokens to the client certificate >>> with public clients. >>> >>> I'm struggling to see the fix as pretty easy, however, given the text o= f >>> the abstract (copied below for ease of reference) and the content and s= cope >>> of the document. >>> >>> Do you think changing the first sentence to have "certificate-bound >>> access and refresh tokens" is sufficient (and accurate)? >>> >>> Or something more or different? In which case proposed text is always >>> welcome. >>> >>> Abstract >>> >>> This document describes OAuth client authentication and certificate- >>> bound access tokens using mutual Transport Layer Security (TLS) >>> authentication with X.509 certificates. OAuth clients are provided = a >>> mechanism for authentication to the authorization server using mutua= l >>> TLS, based on either self-signed certificates or public key >>> infrastructure (PKI). OAuth authorization servers are provided a >>> mechanism for binding access tokens to a client's mutual TLS >>> certificate, and OAuth protected resources are provided a method for >>> ensuring that such an access token presented to it was issued to the >>> client presenting the token. >>> >>> >>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci >> 40auth0.com@dmarc.ietf.org> wrote: >>> >>>> Hi all, >>>> during today's office hours call I pointed out that oauth-mtls-13's ab= stract >>>> only mentions access token, although the spec does provide (some) guid= ance >>>> on refresh token binding as well.. >>>> Although in the end implementers would do the right thing, given that >>>> they have to read the spec in its entirety, having a mention of refres= h >>>> tokens in the abstract as well would make it easier for superficial re= aders >>>> to learn that the spec does address RTs as well. Refresh tokens leakag= e is >>>> one of the top concerns of the customers I deal with, and those people >>>> rarely read specs from cover to cover: having language in the abstract >>>> explicitly calling out RTs might make some conversations easier. >>>> >>>> This is admittedly very minor, but the fix would also be pretty easy, >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly >>> prohibited... If you have received this communication in error, please >>> notify the sender immediately by e-mail and delete the message and any = file >>> attachments from your computer. Thank you.* >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000a8d07505840d1159 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, s= o regular old RFC 6749 OAuth requires that a refresh token be bound to the = client to whom it was issued. And that confidential clients (those having e= stablished authn credentials) authenticate to the AS when presenting a refr= esh token. Thus, for both MTLS methods of OAuth client authentication, refr= esh tokens are indirectly certificate-bound through their binding to a clie= nt and its credentials (and the client rotating its cert doesn't invali= date the refresh token).

What was adde= d in the -13 revision of the draft (in a new section https://tools.ietf.org= /html/draft-ietf-oauth-mtls-13#section-4) was a brief description of ce= rtificate binding refresh tokens for public clients.

The ask from Vittorio was a mention of refresh tokens in abstract. Which= seems reasonable. But the proper wording to succinctly and accurately conv= ey the aforementioned subtleties is proving difficult for me.




<= /div>

On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <neil.madden@forgerock.= com> wrote:
Right - this i= s what we have implemented. No support for certificate-bound refresh tokens= , the client can be configured to require TLS cert client authentication in= stead.=C2=A0

Neil

On 14 Mar 2019, at 08:09, Filip Skokan <panva.ip@gmail.com> wrote:=

P= oint being that since the refresh token is only usable on the IdP then mtls= client auth already covers this, and since RTs are long-lasting, it does t= his better because cert rotation is possible for both mtls methods.
S pozdravem,
Filip Skokan


On Thu, 14 Mar 2019 at 08:07, Filip Skokan <panva..ip@gmail.com&= gt; wrote:
Even before refresh tokens were mentioned in draft 13 i wa= s about to implement this binding in nodejs oidc-provider,
the thing i struggled with and ultimately didn't do this w= as

1) if the refresh token is bound to a specific = cert then this cert rotation is out of the question
2) if having = the RT somehow covered is needed, isn't MTLS client auth already the ri= ght thing to do? Especially given it supports cert rotation

<= /div>
Now the normative language is SHOULD therefore disallowing cert r= otation. Or am I missing=C2=A0something?

S pozdravem,
Filip Skokan<= /b>


On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcampbe= ll=3D40pingidentity.com@dmarc.ietf.org> wrote:
As= I kinda said on that call, I understand the ask and I do think it'd be= reasonable to mention refresh tokens in the abstract now that the document= does describe binding refresh tokens to the client certificate with public= clients.

I'm struggling to see the fix a= s pretty easy, however, given the text of the abstract (copied below for ea= se of reference) and the content and scope of the document.
=
Do you think changing the first sentence to have "certi= ficate-bound access and refresh tokens" is sufficient (and accurate)? =

Or something more or different? In which case= proposed text is always welcome.

Abstrac=
t

   This document describes OAuth client authentication and certificate-
   bound access tokens using mutual Transport Layer Security (TLS)
   authentication with X.509 certificates.  OAuth clients are provided a
   mechanism for authentication to the authorization server using mutual
   TLS, based on either self-signed certificates or public key
   infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.

On Mon, Mar 11, 2019 at 4:= 06 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wro= te:
Hi all,
during today's office hours call I pointed out that=C2= =A0oauth-mtls-13= 9;s=C2=A0abstract only mentions access token, although the spec does= provide (some) guidance on=C2=A0 refresh token binding as well..=C2=A0
Although in the end implementers would do the right thing, given tha= t they have to read the spec in its entirety, having a mention of refresh t= okens in the abstract as well would make it easier for superficial readers = to learn that the spec does address RTs as well. Refresh tokens leakage is = one of the top concerns of the customers I deal with, and those people rare= ly read specs from cover to cover: having language in the abstract explicit= ly calling out RTs might make some conversations easier.

This is admittedly very minor, but the fix would also be pretty easy= ,=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited...=C2=A0 If you have received this communication in e= rror, please notify the sender immediately by e-mail and delete the message= and any file attachments from your computer. Thank you._= ______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______= ________________________________________
OAuth mailing list=
OAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth=

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000a8d07505840d1159-- From nobody Thu Mar 14 05:53:38 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A984C129515 for ; Thu, 14 Mar 2019 05:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 X2kAAutPwUed for ; Thu, 14 Mar 2019 05:53:34 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D566F12008F for ; Thu, 14 Mar 2019 05:53:33 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id z14so4295383oid.0 for ; Thu, 14 Mar 2019 05:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=az3PSJRPIlRdnbD2DvoByW84uQv8C+U8RytpORXjWR4=; b=kf8lLn/PkZtcadJEVtupm6OkLs/x2k8eBkGwefNjL//SYwUqxahUuB2aLf3mrv3siB IFmGkcYpAC4emGoF5n59wICZChWM4AIJAei/6wU67vtgg3//GB3AU9hsYN035v4zgiU5 xuCERJKcOMJHb+m+O6QqraKI5OnNXCsfalTCwWlO6blO6KDo4gYsARHC44iP2Bs4GifA 9YJiQ5d12PVJLVZrrylTDsn5FKxZlmhW49lU7pmKIrBa9kigACd+S4JJvuH31sZyzvnT +dh9R/4E1/pSGgQ6ZSzQEJUVHXGIvwblOhAc0p/4glWrPiTenyB4k/kKORmHXc3YvDRl yeIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=az3PSJRPIlRdnbD2DvoByW84uQv8C+U8RytpORXjWR4=; b=fcZ+VKy3uPBQXdxBJcZYKXUt74Wwp4f8VKhH8QKs+lf87P9N7I58/XXbggDwQcLCSz yyJI4US7rFOn0LSCOarXDeAd6crFOBOrSD5ki/kJaiqp6LosRVWTOIUN/JAwNBSkRSbC YjBTF+HTV13vbuI1GBK/1nCgJePjaxZvEhoVnsQozBYVuwFpS9mLc4iIWI3v/LUM8Bxk fSUy0mTliqDbP+SZr0icfqZ4JWJssDjkNL5NVEL8CmjJxYfAlKMgM/8KrOXnb/H+6x2G qK5cwyv/juGMgiPvMOP7N7nZshpydz7YxUP7Q0Xjua1dcFyn41HlAgRh8ybhb8eC57jB 3tjA== X-Gm-Message-State: APjAAAUhRpIq0Yhq+TNJfiYXeyEpOqnmmeA7q32GgOiucEpQ7lulqypE 6wtNYtXc+xTCW1povp86sqPBAuyodW1IgIfEBA== X-Google-Smtp-Source: APXvYqyGyuQGvya0NFkCtznNC/6VixLrDhoeciU5Fib4HVlCrLunjcraPdXtqX49jExWAXmHWXAN4zhatG6c5KDTi0U= X-Received: by 2002:aca:b4d6:: with SMTP id d205mr1941534oif.13.1552568012994; Thu, 14 Mar 2019 05:53:32 -0700 (PDT) MIME-Version: 1.0 References: <5428A862-D273-42F0-8E7A-9D3FFF191F0E@forgerock.com> In-Reply-To: From: Filip Skokan Date: Thu, 14 Mar 2019 13:53:21 +0100 Message-ID: To: Brian Campbell Cc: Neil Madden , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000e77f3605840d684a" Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 12:53:37 -0000 --000000000000e77f3605840d684a Content-Type: text/plain; charset="UTF-8" Thank you for the clarification Brian, this makes sense. So for clients not using mtls (or is this only clients using "none"?) to authenticate the tls_client_certificate_bound_access_tokens client metadata property also conditions binding the refresh token. At the cost of the RT being unusable if the client loses or rotates the certificate. Best, *Filip* On Thu, 14 Mar 2019 at 13:29, Brian Campbell wrote: > Yeah, so regular old RFC 6749 OAuth requires that a refresh token be bound > to the client to whom it was issued. And that confidential clients (those > having established authn credentials) authenticate to the AS when > presenting a refresh token. Thus, for both MTLS methods of OAuth client > authentication, refresh tokens are indirectly certificate-bound through > their binding to a client and its credentials (and the client rotating its > cert doesn't invalidate the refresh token). > > What was added in the -13 revision of the draft (in a new section > https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a > brief description of certificate binding refresh tokens for public clients. > > The ask from Vittorio was a mention of refresh tokens in abstract. Which > seems reasonable. But the proper wording to succinctly and accurately > convey the aforementioned subtleties is proving difficult for me. > > > > > > On Thu, Mar 14, 2019 at 2:26 AM Neil Madden > wrote: > >> Right - this is what we have implemented. No support for >> certificate-bound refresh tokens, the client can be configured to require >> TLS cert client authentication instead. >> >> Neil >> >> On 14 Mar 2019, at 08:09, Filip Skokan wrote: >> >> Point being that since the refresh token is only usable on the IdP then >> mtls client auth already covers this, and since RTs are long-lasting, it >> does this better because cert rotation is possible for both mtls methods. >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Thu, 14 Mar 2019 at 08:07, Filip Skokan > > wrote: >> >>> Even before refresh tokens were mentioned in draft 13 i was about to >>> implement this binding in nodejs oidc-provider, >>> >>> the thing i struggled with and ultimately didn't do this was >>> >>> 1) if the refresh token is bound to a specific cert then this cert >>> rotation is out of the question >>> 2) if having the RT somehow covered is needed, isn't MTLS client auth >>> already the right thing to do? Especially given it supports cert rotation >>> >>> Now the normative language is SHOULD therefore disallowing cert >>> rotation. Or am I missing something? >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell >> 40pingidentity.com@dmarc.ietf.org> wrote: >>> >>>> As I kinda said on that call, I understand the ask and I do think it'd >>>> be reasonable to mention refresh tokens in the abstract now that the >>>> document does describe binding refresh tokens to the client certificate >>>> with public clients. >>>> >>>> I'm struggling to see the fix as pretty easy, however, given the text >>>> of the abstract (copied below for ease of reference) and the content and >>>> scope of the document. >>>> >>>> Do you think changing the first sentence to have "certificate-bound >>>> access and refresh tokens" is sufficient (and accurate)? >>>> >>>> Or something more or different? In which case proposed text is always >>>> welcome. >>>> >>>> Abstract >>>> >>>> This document describes OAuth client authentication and certificate- >>>> bound access tokens using mutual Transport Layer Security (TLS) >>>> authentication with X.509 certificates. OAuth clients are provided a >>>> mechanism for authentication to the authorization server using mutual >>>> TLS, based on either self-signed certificates or public key >>>> infrastructure (PKI). OAuth authorization servers are provided a >>>> mechanism for binding access tokens to a client's mutual TLS >>>> certificate, and OAuth protected resources are provided a method for >>>> ensuring that such an access token presented to it was issued to the >>>> client presenting the token. >>>> >>>> >>>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci >>> 40auth0.com@dmarc.ietf.org> wrote: >>>> >>>>> Hi all, >>>>> during today's office hours call I pointed out that oauth-mtls-13's abstract >>>>> only mentions access token, although the spec does provide (some) guidance >>>>> on refresh token binding as well.. >>>>> Although in the end implementers would do the right thing, given that >>>>> they have to read the spec in its entirety, having a mention of refresh >>>>> tokens in the abstract as well would make it easier for superficial readers >>>>> to learn that the spec does address RTs as well. Refresh tokens leakage is >>>>> one of the top concerns of the customers I deal with, and those people >>>>> rarely read specs from cover to cover: having language in the abstract >>>>> explicitly calling out RTs might make some conversations easier. >>>>> >>>>> This is admittedly very minor, but the fix would also be pretty easy, >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly >>>> prohibited... If you have received this communication in error, please >>>> notify the sender immediately by e-mail and delete the message and any file >>>> attachments from your computer. Thank you.* >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* --000000000000e77f3605840d684a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the clarification Bria= n, this makes sense.=C2=A0

So for clients not usin= g mtls (or is this only clients using "none"?) to authenticate th= e=C2=A0tls_client_certificate_bound_access_tokens client metadata property = also conditions binding the refresh token. At the cost of the RT being unus= able if the client loses or rotates the certificate.

Best,
Filip


On Thu, 14 Mar 2019 at 13:29, Brian Campbell <bcampbell@pingidentity.com> w= rote:
Yeah, so regula= r old RFC 6749 OAuth requires that a refresh token be bound to the client t= o whom it was issued. And that confidential clients (those having establish= ed authn credentials) authenticate to the AS when presenting a refresh toke= n. Thus, for both MTLS methods of OAuth client authentication, refresh toke= ns are indirectly certificate-bound through their binding to a client and i= ts credentials (and the client rotating its cert doesn't invalidate the= refresh token).

What was added in the= -13 revision of the draft (in a new section https://tool= s.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a brief descrip= tion of certificate binding refresh tokens for public clients.
The ask from Vittorio was a mention of refresh tokens in abstr= act. Which seems reasonable. But the proper wording to succinctly and accur= ately convey the aforementioned subtleties is proving difficult for me.
=





On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <= neil.madden@= forgerock.com> wrote:
Righ= t - this is what we have implemented. No support for certificate-bound refr= esh tokens, the client can be configured to require TLS cert client authent= ication instead.=C2=A0

Nei= l

On 14 Mar 2019, at 08:09, Filip Skokan <panva.ip@gmail.com&= gt; wrote:

Point being that since the refresh token is only usable on the IdP= then mtls client auth already covers this, and since RTs are long-lasting,= it does this better because cert rotation is possible for both mtls method= s.

S pozdravem,
Filip Skokan


On Thu, 14 Mar= 2019 at 08:07, Filip Skokan <panva..ip@gmail.com> wrote:
Even before refresh = tokens were mentioned in draft 13 i was about to implement this binding in = nodejs oidc-provider,

the thing i struggled wi= th and ultimately didn't do this was

1) if the= refresh token is bound to a specific cert then this cert rotation is out o= f the question
2) if having the RT somehow covered is needed, isn= 't MTLS client auth already the right thing to do? Especially given it = supports cert rotation

Now the normative language = is SHOULD therefore disallowing cert rotation. Or am I missing=C2=A0somethi= ng?

S pozdravem,
Filip Skokan
=


On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcampbell=3D40pingid= entity.com@dmarc.ietf.org> wrote:
As I kinda = said on that call, I understand the ask and I do think it'd be reasonab= le to mention refresh tokens in the abstract now that the document does des= cribe binding refresh tokens to the client certificate with public clients.=

I'm struggling to see the fix as pretty = easy, however, given the text of the abstract (copied below for ease of ref= erence) and the content and scope of the document.

Do you think changing the first sentence to have "certificate-bo= und access and refresh tokens" is sufficient (and accurate)?

Or something more or different? In which case proposed= text is always welcome.

Abstract

   This document describes OAuth client authentication and certificate-
   bound access tokens using mutual Transport Layer Security (TLS)
   authentication with X.509 certificates.  OAuth clients are provided a
   mechanism for authentication to the authorization server using mutual
   TLS, based on either self-signed certificates or public key
   infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.

On Mon, Mar 11, 2019 at 4:= 06 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wro= te:
Hi all,
during today's office hours call I pointed out that=C2= =A0oauth-mtls-13= 9;s=C2=A0abstract only mentions access token, although the spec does= provide (some) guidance on=C2=A0 refresh token binding as well..=C2=A0
Although in the end implementers would do the right thing, given tha= t they have to read the spec in its entirety, having a mention of refresh t= okens in the abstract as well would make it easier for superficial readers = to learn that the spec does address RTs as well. Refresh tokens leakage is = one of the top concerns of the customers I deal with, and those people rare= ly read specs from cover to cover: having language in the abstract explicit= ly calling out RTs might make some conversations easier.

This is admittedly very minor, but the fix would also be pretty easy= ,=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited...=C2=A0 If you have received this communication in e= rror, please notify the sender immediately by e-mail and delete the message= and any file attachments from your computer. Thank you._= ______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______= ________________________________________
OAuth mailing list=
OAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth=

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
--000000000000e77f3605840d684a-- From nobody Thu Mar 14 05:56:11 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B988012008F for ; Thu, 14 Mar 2019 05:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 OUJvSmm_QGjV for ; Thu, 14 Mar 2019 05:56:06 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A14129515 for ; Thu, 14 Mar 2019 05:56:05 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id x3so4943338ior.6 for ; Thu, 14 Mar 2019 05:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TjX4w6etrRazGedPxP+IdXFVYBa6plSZohY1/k/Zrl0=; b=XYBFw9dJp21t1c2S8JyO3d4wGl68d5+6C03x5b1LOLuUHKDgfi1gijztiL49WfcXmA wDZ1eah7AaKjSUUqBBuipblVaTx8rqpJfiyZGLDSiMp1OwYNnGfzgwJ7Kwvx5NdnlNUm QjOkTALoMqLr9cmtubAbCJ1QicjwrDDVAp0Ww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TjX4w6etrRazGedPxP+IdXFVYBa6plSZohY1/k/Zrl0=; b=fgmjaWT1wC8LrkGqNGAeBVqKGwSnX6IAxGPgzB8hFxSdS/foxoeZPV+WgOdLja6+lb MM3w8VJvDmOt9Pqv1X2Qp/3uXo5iowTB5snxYdOmDQpF71v12MXzqAai/Lf+SeC0Hs2I pZ67NKD+SRn0Z+ek9B7muuPV532IP8up+uBsOHqV1tCBn07Vdo8L/duUFicFWVgLhEQv CEEmw4VUQcqGZ62Gplw9oAMNzIjTkTP7XYXCdun3lI6m3QwzlJ2UDwU+MYoaLQDTGdg3 i1zMYcAcXJWDZjwZ961BG6tUfMCg9B8aayIZYh5wC4r7/LuUEDmo/67nMxp3kRp2dCu6 Cg5A== X-Gm-Message-State: APjAAAXZ1byzxIgIqtDagcQ1FUcIaB9QrtrhYsrtsI7SlQKGoLoDXSB7 9zGYntVfdzlH2qW4QPSSZNxDHgXrEmzKmel8SQ7/saKVp/rkwEZudvKWMn7ax4TCPNpVN8XYBY3 AdXKWond5flBCQQ== X-Google-Smtp-Source: APXvYqwkA7wWi4ZPf06RZQG9pvjrVFvvG1LilNGBjmUR9aFoMhLt8zmvKKHs6/3BTZg8nB8xqfOwKYuRPoS9+P6dgv8= X-Received: by 2002:a5d:878a:: with SMTP id f10mr1175132ion.238.1552568164994; Thu, 14 Mar 2019 05:56:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Thu, 14 Mar 2019 06:55:38 -0600 Message-ID: To: Lars Wilhelmsen Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="000000000000f6f09b05840d71bb" Archived-At: Subject: Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 12:56:09 -0000 --000000000000f6f09b05840d71bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are icon links for audio and video next to the sessions on the agenda at https://datatracker.ietf.org/meeting/104/agenda/. I believe registration is required (but is free for remote participants). See https://www.ietf.org/how/meetings/104/remote/ for more official information. Recordings will be available after the fact at some point on the proceedings at https://datatracker.ietf.org/meeting/104/proceedings (here's the the previous meeting's proceedings for example https://datatracker.ietf.org/meeting/103/proceedings). On Thu, Mar 14, 2019 at 2:17 AM Lars Wilhelmsen wrote: > Hi, > > > > Are these sessions recorded / available to follow online? > > > > Regards, > > --larsw > > > > *From:* OAuth *On Behalf Of *Rifaat Shekh-Yusef > *Sent:* onsdag 13. mars 2019 18:46 > *To:* oauth > *Subject:* Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings > > > > Use the following links instead: > > https://datatracker.ietf.org/doc/agenda-104-oauth-sessa/ > > https://datatracker.ietf.org/doc/agenda-104-oauth-sessb/ > > > > Regards, > > Rifaat > > > > > > On Wed, Mar 13, 2019 at 1:37 PM Rifaat Shekh-Yusef > wrote: > > All, > > > > The following links have our draft agenda for the two sessions: > > > > > https://datatracker.ietf.org/meeting/104/materials/agenda-104-oauth-sessa= -00 > > > https://datatracker.ietf.org/meeting/104/materials/agenda-104-oauth-sessb= -00 > > > > Please, take a look and let us know if you have any comments. > > > > Regards, > > Rifaat & Hannes > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000f6f09b05840d71bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Th= ere are icon links for audio and video next to the sessions on the agenda a= t https://data= tracker.ietf.org/meeting/104/agenda/. I believe registration is require= d (but is free for remote participants). See https://www.ietf.org/how/meetings/104/remote/ for more official information.


On Thu, Mar 14, 2019 at 2:17 AM Lars Wilh= elmsen <Lars.Wilhelmsen=3D= 40Thales.no@dmarc.ietf.org> wrote:

Hi,

=C2=A0

Are these session= s recorded / available to follow online?

=C2=A0<= /u>

Regards,

=C2=A0 --larsw=

=C2=A0<= /u>

From: OAut= h <oauth-bou= nces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: onsdag 13. mars 2019 18:46
To: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings

=C2=A0

=C2=A0

On Wed, Mar 13, 2019 at 1:37 PM Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:

All,

=C2=A0

The following links have our draft agenda for the tw= o sessions:

=C2=A0

=C2=A0

Please, take a look and let us know if you have any = comments.

=C2=A0

Regards,

=C2=A0Rifaat & Hannes

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000f6f09b05840d71bb-- From nobody Thu Mar 14 06:14:09 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60FE130E86 for ; Thu, 14 Mar 2019 06:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com 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 3k-Jgo0K8WoV for ; Thu, 14 Mar 2019 06:14:00 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C594130E91 for ; Thu, 14 Mar 2019 06:14:00 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id i8so5832353wrm.0 for ; Thu, 14 Mar 2019 06:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oT3bnNCWG1daC0J7QJG1Xxojg73oM5M6K5dXVG+srLM=; b=faJufbq27Nyu+nzY5777unu0WYpWlvbcOerNKK7hVx3X+cQtZa8yf5wvPbUUrhqUL+ XEA328lxe+ieEDsGbcTeGxMPDPyjXUornjZEZCneRimvmbG5vb4hbNhucVnpccQo1xI2 oHP15qqt7aEuo15HWQTRDaAciIA+CyByr9OqA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oT3bnNCWG1daC0J7QJG1Xxojg73oM5M6K5dXVG+srLM=; b=bpkmEZwqjeKW1uubJor9a1+PpHrSI0Wyym/99oOTsXLcLTCdHqoZDWIS40jA+R/KAk P6mpWzrCVsvTVdmxrd4ddt/orsfNY7nQU4IWqRec8gzP6aIobmHvXIvNvVHejqqmNLLj /92gOJAWyjRQQkiD3Nv0fiTevg4/+zS6iZgYOfF4FVCP1L2W0vsr9HSVlGCUmbFmddZp BxKWd1WTSPArlpQDm9Lva1HCTpi0ZsADKoLWXpNWzxjPm0z9m6c7PWdbLk5Eg/MZ3eR5 NkufnglhQdUWq3ay5aAv1jIj3uCt2sUEJszlmO3BUqL328cdqD75D9z8nrM24wGKqBK9 I/GQ== X-Gm-Message-State: APjAAAXOfoaSv3ENasVTWtlVlugSKhPabX4gUef0xQPZbruIE28qBw1+ e61n2TwU6MKP3ygT4iAL3Er7jw== X-Google-Smtp-Source: APXvYqyoi0R/TlA+aSWQ8EhE8gKWg7EHaj2+XqeMUWAZmfyerFqDqhFayNFJtJXJOphTgXVSx3a/sA== X-Received: by 2002:adf:f681:: with SMTP id v1mr2100259wrp.113.1552569238303; Thu, 14 Mar 2019 06:13:58 -0700 (PDT) Received: from guest2s-mbp.lan (88.33.198.146.dyn.plus.net. [146.198.33.88]) by smtp.gmail.com with ESMTPSA id r10sm209685wmh.21.2019.03.14.06.13.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 06:13:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Neil Madden In-Reply-To: Date: Thu, 14 Mar 2019 13:13:56 +0000 Cc: Filip Skokan , IETF oauth WG Content-Transfer-Encoding: quoted-printable Message-Id: <41D2946C-7D10-4FF2-B5E9-D861896636AF@forgerock.com> References: <5428A862-D273-42F0-8E7A-9D3FFF191F0E@forgerock.com> To: Brian Campbell X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 13:14:07 -0000 It=E2=80=99s not clear to me how this works or what problem it is = solving. If a refresh token is bound to the certificate, does that mean = that a call to the introspection endpoint with that refresh token should = also return a =E2=80=9Ccnf=E2=80=9D claim as per = https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ?=20 It also seems problematic to implement this for refresh tokens. As = mentioned by Filip, rotation of the certificate is out of the question. = Currently in our implementation a client could present a new certificate = when using the refresh token and this would result in the newly issued = access token being bound to the new certificate. If the refresh token is = bound to the original certificate, then this would be ruled out (the new = certificate would be rejected) and certificate rotation becomes = impossible in all cases. Am I missing something? =E2=80=94 Neil > On 14 Mar 2019, at 12:28, Brian Campbell = wrote: >=20 > Yeah, so regular old RFC 6749 OAuth requires that a refresh token be = bound to the client to whom it was issued. And that confidential clients = (those having established authn credentials) authenticate to the AS when = presenting a refresh token. Thus, for both MTLS methods of OAuth client = authentication, refresh tokens are indirectly certificate-bound through = their binding to a client and its credentials (and the client rotating = its cert doesn't invalidate the refresh token). >=20 > What was added in the -13 revision of the draft (in a new section = https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a = brief description of certificate binding refresh tokens for public = clients. >=20 > The ask from Vittorio was a mention of refresh tokens in abstract. = Which seems reasonable. But the proper wording to succinctly and = accurately convey the aforementioned subtleties is proving difficult for = me. >=20 >=20 >=20 >=20 >=20 > On Thu, Mar 14, 2019 at 2:26 AM Neil Madden = wrote: > Right - this is what we have implemented. No support for = certificate-bound refresh tokens, the client can be configured to = require TLS cert client authentication instead.=20 >=20 > Neil >=20 > On 14 Mar 2019, at 08:09, Filip Skokan wrote: >=20 >> Point being that since the refresh token is only usable on the IdP = then mtls client auth already covers this, and since RTs are = long-lasting, it does this better because cert rotation is possible for = both mtls methods. >>=20 >> S pozdravem, >> Filip Skokan >>=20 >>=20 >> On Thu, 14 Mar 2019 at 08:07, Filip Skokan = wrote: >> Even before refresh tokens were mentioned in draft 13 i was about to = implement this binding in nodejs oidc-provider, >>=20 >> the thing i struggled with and ultimately didn't do this was >>=20 >> 1) if the refresh token is bound to a specific cert then this cert = rotation is out of the question >> 2) if having the RT somehow covered is needed, isn't MTLS client auth = already the right thing to do? Especially given it supports cert = rotation >>=20 >> Now the normative language is SHOULD therefore disallowing cert = rotation. Or am I missing something? >>=20 >> S pozdravem, >> Filip Skokan >>=20 >>=20 >> On Thu, 14 Mar 2019 at 00:21, Brian Campbell = wrote: >> As I kinda said on that call, I understand the ask and I do think = it'd be reasonable to mention refresh tokens in the abstract now that = the document does describe binding refresh tokens to the client = certificate with public clients.=20 >>=20 >> I'm struggling to see the fix as pretty easy, however, given the text = of the abstract (copied below for ease of reference) and the content and = scope of the document.=20 >>=20 >> Do you think changing the first sentence to have "certificate-bound = access and refresh tokens" is sufficient (and accurate)?=20 >>=20 >> Or something more or different? In which case proposed text is always = welcome. >>=20 >> Abstract >>=20 >> This document describes OAuth client authentication and = certificate- >> bound access tokens using mutual Transport Layer Security (TLS) >> authentication with X.509 certificates. OAuth clients are = provided a >> mechanism for authentication to the authorization server using = mutual >> TLS, based on either self-signed certificates or public key >> infrastructure (PKI). OAuth authorization servers are provided a >> mechanism for binding access tokens to a client's mutual TLS >> certificate, and OAuth protected resources are provided a method = for >> ensuring that such an access token presented to it was issued to = the >> client presenting the token. >>=20 >>=20 >> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci = wrote: >> Hi all, >> during today's office hours call I pointed out that oauth-mtls-13's = abstract only mentions access token, although the spec does provide = (some) guidance on refresh token binding as well..=20 >> Although in the end implementers would do the right thing, given that = they have to read the spec in its entirety, having a mention of refresh = tokens in the abstract as well would make it easier for superficial = readers to learn that the spec does address RTs as well. Refresh tokens = leakage is one of the top concerns of the customers I deal with, and = those people rarely read specs from cover to cover: having language in = the abstract explicitly calling out RTs might make some conversations = easier. >>=20 >> This is admittedly very minor, but the fix would also be pretty easy,=20= >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited... If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. From nobody Thu Mar 14 06:57:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EAC130E9F for ; Thu, 14 Mar 2019 06:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 OIqBj5KIPeVs for ; Thu, 14 Mar 2019 06:57:36 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18405130E9C for ; Thu, 14 Mar 2019 06:57:36 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id f6so5163236iop.3 for ; Thu, 14 Mar 2019 06:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aevMToyeuvIKvQcUwnIGRvorVrFCKwg1hN50+70DM6E=; b=KpXwcjxLl6S+j0FCZMgCmT6kprpLDgz0EctpsvcNKoFOg6FrlcKWDFRQRA7KA4s9bp hwxSBOLEpicmDuQd0WmtN7+Y88SnQ3MfFpk4dR8Bt8ISt2oCoBxn2C/2qD4PrhHGhIAV MmojiQiYLZUb3qH5I+DGPDDLln7tHiQUgmuo8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aevMToyeuvIKvQcUwnIGRvorVrFCKwg1hN50+70DM6E=; b=i3uvUuB4/3i61iu/UmoerrgjVg6cY4tGhLBe1DLSz47//yDI0E+/YEREk143zWn3Vu DW/hDAj/efx3ey4klTZ+9ycyB56gi1D8/H4E8XY2D5cLGrVK1Rf0sAsDmEduK/NnQdNL 8lqUAvXb1TryqHIsmKDxaYnQivRvcIq9OEbNn7oNtiQinFDalejgyCD48OOMK8P4GkU2 +Yqt1lBUSb3KfxSXX4V8DPgPxGcPzVCF01/pmFINf3fs67N7RfRgMZeaHz78v+m/RwwG hDG9AGKdnQ6hvtqcqiau6hJEsNHXDGK04uufPDGzM+ZEEGZq8HzTKC5TDOiRBtcWYNFB T5vw== X-Gm-Message-State: APjAAAVrPfiTA6CesSdXvWXtmUNDNpcFXR+njYUHr8d6jlE9qlcF8bIJ cMUthCd7OrrXrQQLse2k2n0gvmcagd8QRiCfXRjfmOiOdPxIINHR6OTSmg6XYLmBrjMAA+W9Y1Q qJFErjZeLUIB7BQ== X-Google-Smtp-Source: APXvYqyNj/vzG7Bo9jSrcQyhmuFi2nxTWgZZ8q+uQ/+WBt/q4MaKgHyJDY/Q6n1dSV4yDtionw9Z1GLCuytd3orIt5c= X-Received: by 2002:a6b:cdca:: with SMTP id d193mr26703348iog.59.1552571855207; Thu, 14 Mar 2019 06:57:35 -0700 (PDT) MIME-Version: 1.0 References: <5428A862-D273-42F0-8E7A-9D3FFF191F0E@forgerock.com> In-Reply-To: From: Brian Campbell Date: Thu, 14 Mar 2019 07:57:08 -0600 Message-ID: To: Filip Skokan Cc: Neil Madden , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000eb2b1805840e4d07" Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 13:57:42 -0000 --000000000000eb2b1805840e4d07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah Filip, that's about right. Currently the text says to do it only for public clients (clients using "none"). On Thu, Mar 14, 2019 at 6:53 AM Filip Skokan wrote: > Thank you for the clarification Brian, this makes sense. > > So for clients not using mtls (or is this only clients using "none"?) to > authenticate the tls_client_certificate_bound_access_tokens client metada= ta > property also conditions binding the refresh token. At the cost of the RT > being unusable if the client loses or rotates the certificate. > > Best, > *Filip* > > > On Thu, 14 Mar 2019 at 13:29, Brian Campbell > wrote: > >> Yeah, so regular old RFC 6749 OAuth requires that a refresh token be >> bound to the client to whom it was issued. And that confidential clients >> (those having established authn credentials) authenticate to the AS when >> presenting a refresh token. Thus, for both MTLS methods of OAuth client >> authentication, refresh tokens are indirectly certificate-bound through >> their binding to a client and its credentials (and the client rotating i= ts >> cert doesn't invalidate the refresh token). >> >> What was added in the -13 revision of the draft (in a new section >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a >> brief description of certificate binding refresh tokens for public clien= ts. >> >> The ask from Vittorio was a mention of refresh tokens in abstract. Which >> seems reasonable. But the proper wording to succinctly and accurately >> convey the aforementioned subtleties is proving difficult for me. >> >> >> >> >> >> On Thu, Mar 14, 2019 at 2:26 AM Neil Madden >> wrote: >> >>> Right - this is what we have implemented. No support for >>> certificate-bound refresh tokens, the client can be configured to requi= re >>> TLS cert client authentication instead. >>> >>> Neil >>> >>> On 14 Mar 2019, at 08:09, Filip Skokan wrote: >>> >>> Point being that since the refresh token is only usable on the IdP then >>> mtls client auth already covers this, and since RTs are long-lasting, i= t >>> does this better because cert rotation is possible for both mtls method= s. >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Thu, 14 Mar 2019 at 08:07, Filip Skokan >> > wrote: >>> >>>> Even before refresh tokens were mentioned in draft 13 i was about to >>>> implement this binding in nodejs oidc-provider, >>>> >>>> the thing i struggled with and ultimately didn't do this was >>>> >>>> 1) if the refresh token is bound to a specific cert then this cert >>>> rotation is out of the question >>>> 2) if having the RT somehow covered is needed, isn't MTLS client auth >>>> already the right thing to do? Especially given it supports cert rotat= ion >>>> >>>> Now the normative language is SHOULD therefore disallowing cert >>>> rotation. Or am I missing something? >>>> >>>> S pozdravem, >>>> *Filip Skokan* >>>> >>>> >>>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell >>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>> >>>>> As I kinda said on that call, I understand the ask and I do think it'= d >>>>> be reasonable to mention refresh tokens in the abstract now that the >>>>> document does describe binding refresh tokens to the client certifica= te >>>>> with public clients. >>>>> >>>>> I'm struggling to see the fix as pretty easy, however, given the text >>>>> of the abstract (copied below for ease of reference) and the content = and >>>>> scope of the document. >>>>> >>>>> Do you think changing the first sentence to have "certificate-bound >>>>> access and refresh tokens" is sufficient (and accurate)? >>>>> >>>>> Or something more or different? In which case proposed text is always >>>>> welcome. >>>>> >>>>> Abstract >>>>> >>>>> This document describes OAuth client authentication and certificat= e- >>>>> bound access tokens using mutual Transport Layer Security (TLS) >>>>> authentication with X.509 certificates. OAuth clients are provide= d a >>>>> mechanism for authentication to the authorization server using mut= ual >>>>> TLS, based on either self-signed certificates or public key >>>>> infrastructure (PKI). OAuth authorization servers are provided a >>>>> mechanism for binding access tokens to a client's mutual TLS >>>>> certificate, and OAuth protected resources are provided a method f= or >>>>> ensuring that such an access token presented to it was issued to t= he >>>>> client presenting the token. >>>>> >>>>> >>>>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci >>>> 40auth0.com@dmarc.ietf.org> wrote: >>>>> >>>>>> Hi all, >>>>>> during today's office hours call I pointed out that oauth-mtls-13's = abstract >>>>>> only mentions access token, although the spec does provide (some) gu= idance >>>>>> on refresh token binding as well.. >>>>>> Although in the end implementers would do the right thing, given tha= t >>>>>> they have to read the spec in its entirety, having a mention of refr= esh >>>>>> tokens in the abstract as well would make it easier for superficial = readers >>>>>> to learn that the spec does address RTs as well. Refresh tokens leak= age is >>>>>> one of the top concerns of the customers I deal with, and those peop= le >>>>>> rarely read specs from cover to cover: having language in the abstra= ct >>>>>> explicitly calling out RTs might make some conversations easier. >>>>>> >>>>>> This is admittedly very minor, but the fix would also be pretty easy= , >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). An= y >>>>> review, use, distribution or disclosure by others is strictly >>>>> prohibited... If you have received this communication in error, plea= se >>>>> notify the sender immediately by e-mail and delete the message and an= y file >>>>> attachments from your computer. Thank you.* >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000eb2b1805840e4d07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah Filip, that's about right. Currently the text say= s to do it only for public clients (clients using "none").=C2=A0<= /div>
O= n Thu, Mar 14, 2019 at 6:53 AM Filip Skokan <panva.ip@gmail.com> wrote:
Thank y= ou for the clarification Brian, this makes sense.=C2=A0

So for clients not using mtls (or is this only clients using "no= ne"?) to authenticate the=C2=A0tls_client_certificate_bound_access_tok= ens client metadata property also conditions binding the refresh token. At = the cost of the RT being unusable if the client loses or rotates the certif= icate.

Best,
Filip

<= /div>
O= n Thu, 14 Mar 2019 at 13:29, Brian Campbell <bcampbell@pingidentity.com> wro= te:
Yeah, so regular ol= d RFC 6749 OAuth requires that a refresh token be bound to the client to wh= om it was issued. And that confidential clients (those having established a= uthn credentials) authenticate to the AS when presenting a refresh token. T= hus, for both MTLS methods of OAuth client authentication, refresh tokens a= re indirectly certificate-bound through their binding to a client and its c= redentials (and the client rotating its cert doesn't invalidate the ref= resh token).

What was added in the -13= revision of the draft (in a new section https://tools.ie= tf.org/html/draft-ietf-oauth-mtls-13#section-4) was a brief description= of certificate binding refresh tokens for public clients.

The ask from Vittorio was a mention of refresh tokens in abstract.= Which seems reasonable. But the proper wording to succinctly and accuratel= y convey the aforementioned subtleties is proving difficult for me.





On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <neil.madden@forg= erock.com> wrote:
Right = - this is what we have implemented. No support for certificate-bound refres= h tokens, the client can be configured to require TLS cert client authentic= ation instead.=C2=A0

Neil<= /div>

On 14 Mar 2019, at 08:09, Filip Skokan <panva.ip@gmail.com>= ; wrote:

Point being that since the refresh token is only usable on the IdP= then mtls client auth already covers this, and since RTs are long-lasting,= it does this better because cert rotation is possible for both mtls method= s.

S pozdravem,
Filip Skokan


On Thu, 14 Mar 2019 at 08:07, Filip Skokan <panva..ip@gmail.com> wro= te:
Even before refresh tokens were mentioned in draft 13 i was about= to implement this binding in nodejs oidc-provider,

the thing i struggled with and ultimately didn't do this was

1) if the refresh token is bound to a specific cert th= en this cert rotation is out of the question
2) if having the RT = somehow covered is needed, isn't MTLS client auth already the right thi= ng to do? Especially given it supports cert rotation

Now the normative language is SHOULD therefore disallowing cert rotation= . Or am I missing=C2=A0something?

S pozdravem,
Filip Skokan

<= br>
On Thu,= 14 Mar 2019 at 00:21, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.= ietf.org> wrote:
As I kinda said on that call= , I understand the ask and I do think it'd be reasonable to mention ref= resh tokens in the abstract now that the document does describe binding ref= resh tokens to the client certificate with public clients.
<= br>
I'm struggling to see the fix as pretty easy, however, gi= ven the text of the abstract (copied below for ease of reference) and the c= ontent and scope of the document.

Do you thin= k changing the first sentence to have "certificate-bound access and re= fresh tokens" is sufficient (and accurate)?

<= div>Or something more or different? In which case proposed text is always w= elcome.

Abstract

   This document describes OAuth client authentication and certificate-
   bound access tokens using mutual Transport Layer Security (TLS)
   authentication with X.509 certificates.  OAuth clients are provided a
   mechanism for authentication to the authorization server using mutual
   TLS, based on either self-signed certificates or public key
   infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.

On Mon, Mar 11, 2019 at 4:= 06 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wro= te:
Hi all,
during today's office hours call I pointed out that=C2= =A0oauth-mtls-13= 9;s=C2=A0abstract only mentions access token, although the spec does= provide (some) guidance on=C2=A0 refresh token binding as well..=C2=A0
Although in the end implementers would do the right thing, given tha= t they have to read the spec in its entirety, having a mention of refresh t= okens in the abstract as well would make it easier for superficial readers = to learn that the spec does address RTs as well. Refresh tokens leakage is = one of the top concerns of the customers I deal with, and those people rare= ly read specs from cover to cover: having language in the abstract explicit= ly calling out RTs might make some conversations easier.

This is admittedly very minor, but the fix would also be pretty easy= ,=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited...=C2=A0 If you have received this communication in e= rror, please notify the sender immediately by e-mail and delete the message= and any file attachments from your computer. Thank you._= ______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______= ________________________________________
OAuth mailing list=
OAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth=

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000eb2b1805840e4d07-- From nobody Thu Mar 14 11:50:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0401312B6 for ; Thu, 14 Mar 2019 11:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 1JK-CMacGdKm for ; Thu, 14 Mar 2019 11:50:28 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE401312EC for ; Thu, 14 Mar 2019 11:50:27 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id u12so6054012iop.11 for ; Thu, 14 Mar 2019 11:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r4JDdsdvEJBXERdnKrNTCrYAHlQ4wHoIxWOcS9GjC1s=; b=FBU6pBSgw+fZDOeTXtk73WQ61ixXZD+pFPpKRukS2t++JWsISaDArTgeCS8oxp6SCb ZREPyhGkG2wzWH+Jh7Eiq8SxUVXfYvoHgbctXdI8uRO0ucsCP/NQUGqznbYKbT7Cf+k1 US4ITp2NdWAV9vBG6rmzvhOmslykizSZH/h84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r4JDdsdvEJBXERdnKrNTCrYAHlQ4wHoIxWOcS9GjC1s=; b=VEaF2gEPFT19V7JEE/+mP+Bg/9oPyi6/6IrOKZRLF95qDdzRillmrM8TMgmAQzdpkp NGuSq6+pqU1v/axXGNFi/mPdBrqY9spwWcJtrX7DqiAyv5z5hy9OD/gYuTHPqsoBt/IJ KSYANIQ1xcZ+s1mfWKAFAVIhd07dIafwbVXJxW/Xf/j4+277OJsS/m4LtQyw7qUccRiU POWX67RSfme5lOdnnTNra6SrXkHJytZ+Fi3pjZXf5plO97hZtMUDikI5fMzDnEqL5o8j /7QzDT7TAsP2mmK2dW+63RCDbPJ9eilIkp6vGgtbUVx/nBko6oj6o4Dr9xTNcMf9PURo pL4A== X-Gm-Message-State: APjAAAV7vUPFmVluy7dCP4kX6RwdlnubuUCKsSI81I/pWTbzCo7szHZt YCDxYFdStVZWFvr/2XiLllmDalGDZdyxP/3HSnWosDNi46RC+0KQRmXhiwsro2fO8BnP3FwoZKe 5tCljjW826o7DVw== X-Google-Smtp-Source: APXvYqw+/s4oo4cM9ghzc6qV7DFHcirLNd+WXNfpEoTgqKlAbh2WshHQSzEnOgrP8WMkSVM/B8dMC35pnMtlGlELIUE= X-Received: by 2002:a6b:5c0a:: with SMTP id z10mr1125736ioh.138.1552589426993; Thu, 14 Mar 2019 11:50:26 -0700 (PDT) MIME-Version: 1.0 References: <5428A862-D273-42F0-8E7A-9D3FFF191F0E@forgerock.com> <41D2946C-7D10-4FF2-B5E9-D861896636AF@forgerock.com> In-Reply-To: <41D2946C-7D10-4FF2-B5E9-D861896636AF@forgerock.com> From: Brian Campbell Date: Thu, 14 Mar 2019 12:50:00 -0600 Message-ID: To: Neil Madden Cc: Filip Skokan , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000474694058412651b" Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 18:50:40 -0000 --000000000000474694058412651b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Certificate-binding refresh tokens issued to *public clients* (those that don't have authentication credentials established with the AS, a.k.a. clients configured or registered with the "none" authentication method, which will typically be native apps on a phone or similar) adds protections against malicious use or reuse of those refresh tokens where no protections would otherwise exist. It's true that certificate rotation in that situation would invalidate the refresh token. But not being able to rotate a strong asymmetric credential without invaliding the refresh token seems a very reasonable trade off vs. not having a credential bound to the token at all. I guess I would say that what is returned when introspecting such a refresh token is an implementation detail that is at the discretion of said implementation. That seems consistent with the level of guidance in introspection for refresh tokens currently. And there's not really an interoperability angle that I can see. So that seems fine. Also, some form of authorization is required to access the introspection endpoint so I'm not sure how a refresh token issued to a public client would realistically get introspected. I guess, if I'm being honest, I don't really get refresh token introspection in general so probably better that I stop opining on the subject. On Thu, Mar 14, 2019 at 7:13 AM Neil Madden wrote: > It=E2=80=99s not clear to me how this works or what problem it is solving= . If a > refresh token is bound to the certificate, does that mean that a call to > the introspection endpoint with that refresh token should also return a > =E2=80=9Ccnf=E2=80=9D claim as per > https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ? > > It also seems problematic to implement this for refresh tokens. As > mentioned by Filip, rotation of the certificate is out of the question. > Currently in our implementation a client could present a new certificate > when using the refresh token and this would result in the newly issued > access token being bound to the new certificate. If the refresh token is > bound to the original certificate, then this would be ruled out (the new > certificate would be rejected) and certificate rotation becomes impossibl= e > in all cases. Am I missing something? > > =E2=80=94 Neil > > > On 14 Mar 2019, at 12:28, Brian Campbell > wrote: > > > > Yeah, so regular old RFC 6749 OAuth requires that a refresh token be > bound to the client to whom it was issued. And that confidential clients > (those having established authn credentials) authenticate to the AS when > presenting a refresh token. Thus, for both MTLS methods of OAuth client > authentication, refresh tokens are indirectly certificate-bound through > their binding to a client and its credentials (and the client rotating it= s > cert doesn't invalidate the refresh token). > > > > What was added in the -13 revision of the draft (in a new section > https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a > brief description of certificate binding refresh tokens for public client= s. > > > > The ask from Vittorio was a mention of refresh tokens in abstract. Whic= h > seems reasonable. But the proper wording to succinctly and accurately > convey the aforementioned subtleties is proving difficult for me. > > > > > > > > > > > > On Thu, Mar 14, 2019 at 2:26 AM Neil Madden > wrote: > > Right - this is what we have implemented. No support for > certificate-bound refresh tokens, the client can be configured to require > TLS cert client authentication instead. > > > > Neil > > > > On 14 Mar 2019, at 08:09, Filip Skokan wrote: > > > >> Point being that since the refresh token is only usable on the IdP the= n > mtls client auth already covers this, and since RTs are long-lasting, it > does this better because cert rotation is possible for both mtls methods. > >> > >> S pozdravem, > >> Filip Skokan > >> > >> > >> On Thu, 14 Mar 2019 at 08:07, Filip Skokan wrote= : > >> Even before refresh tokens were mentioned in draft 13 i was about to > implement this binding in nodejs oidc-provider, > >> > >> the thing i struggled with and ultimately didn't do this was > >> > >> 1) if the refresh token is bound to a specific cert then this cert > rotation is out of the question > >> 2) if having the RT somehow covered is needed, isn't MTLS client auth > already the right thing to do? Especially given it supports cert rotation > >> > >> Now the normative language is SHOULD therefore disallowing cert > rotation. Or am I missing something? > >> > >> S pozdravem, > >> Filip Skokan > >> > >> > >> On Thu, 14 Mar 2019 at 00:21, Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> As I kinda said on that call, I understand the ask and I do think it'd > be reasonable to mention refresh tokens in the abstract now that the > document does describe binding refresh tokens to the client certificate > with public clients. > >> > >> I'm struggling to see the fix as pretty easy, however, given the text > of the abstract (copied below for ease of reference) and the content and > scope of the document. > >> > >> Do you think changing the first sentence to have "certificate-bound > access and refresh tokens" is sufficient (and accurate)? > >> > >> Or something more or different? In which case proposed text is always > welcome. > >> > >> Abstract > >> > >> This document describes OAuth client authentication and certificate= - > >> bound access tokens using mutual Transport Layer Security (TLS) > >> authentication with X.509 certificates. OAuth clients are provided= a > >> mechanism for authentication to the authorization server using mutu= al > >> TLS, based on either self-signed certificates or public key > >> infrastructure (PKI). OAuth authorization servers are provided a > >> mechanism for binding access tokens to a client's mutual TLS > >> certificate, and OAuth protected resources are provided a method fo= r > >> ensuring that such an access token presented to it was issued to th= e > >> client presenting the token. > >> > >> > >> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > >> Hi all, > >> during today's office hours call I pointed out that oauth-mtls-13's > abstract only mentions access token, although the spec does provide (some= ) > guidance on refresh token binding as well.. > >> Although in the end implementers would do the right thing, given that > they have to read the spec in its entirety, having a mention of refresh > tokens in the abstract as well would make it easier for superficial reade= rs > to learn that the spec does address RTs as well. Refresh tokens leakage i= s > one of the top concerns of the customers I deal with, and those people > rarely read specs from cover to cover: having language in the abstract > explicitly calling out RTs might make some conversations easier. > >> > >> This is admittedly very minor, but the fix would also be pretty easy, > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited... If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any fi= le > attachments from your computer. Thank > you._______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000474694058412651b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Certificate-binding refresh tokens issued to *public clients= * (those that don't have authentication credentials established with th= e AS, a.k.a. clients configured or registered with the "none" aut= hentication method, which will typically be native apps on a phone or simil= ar) adds protections against malicious use or reuse of those refresh tokens= where no protections would otherwise exist. It's true that certificate= rotation in that situation would invalidate the refresh token. But not bei= ng able to rotate a strong asymmetric credential without invaliding the ref= resh token seems a very reasonable trade off vs. not having a credential bo= und to the token at all.

I guess I would say = that what is returned when introspecting such a refresh token is an impleme= ntation detail that is at the discretion of said implementation. That seems= consistent with the level of guidance in introspection for refresh tokens = currently. And there's not really an interoperability angle that I can = see. So that seems fine. Also, some form of authorization is required to ac= cess the introspection endpoint so I'm not sure how a refresh token iss= ued to a public client would realistically get introspected. I guess, if I&= #39;m being honest, I don't really get refresh token introspection in g= eneral so probably better that I stop opining on the subject.






On Thu, Mar 14, 2019 at 7:13 AM Neil Madden <neil.madden@for= gerock.com> wrote:
It=E2=80=99s not clear to me how this works or what problem it i= s solving. If a refresh token is bound to the certificate, does that mean t= hat a call to the introspection endpoint with that refresh token should als= o return a =E2=80=9Ccnf=E2=80=9D claim as per https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.= 2 ?

It also seems problematic to implement this for refresh tokens. As mentione= d by Filip, rotation of the certificate is out of the question. Currently i= n our implementation a client could present a new certificate when using th= e refresh token and this would result in the newly issued access token bein= g bound to the new certificate. If the refresh token is bound to the origin= al certificate, then this would be ruled out (the new certificate would be = rejected) and certificate rotation becomes impossible in all cases. Am I mi= ssing something?

=E2=80=94 Neil

> On 14 Mar 2019, at 12:28, Brian Campbell <bcampbell@pingidentity.com> w= rote:
>
> Yeah, so regular old RFC 6749 OAuth requires that a refresh token be b= ound to the client to whom it was issued. And that confidential clients (th= ose having established authn credentials) authenticate to the AS when prese= nting a refresh token. Thus, for both MTLS methods of OAuth client authenti= cation, refresh tokens are indirectly certificate-bound through their bindi= ng to a client and its credentials (and the client rotating its cert doesn&= #39;t invalidate the refresh token).
>
> What was added in the -13 revision of the draft (in a new section https://tools.ietf.org/html/draft-ietf-oa= uth-mtls-13#section-4) was a brief description of certificate binding r= efresh tokens for public clients.
>
> The ask from Vittorio was a mention of refresh tokens in abstract. Whi= ch seems reasonable. But the proper wording to succinctly and accurately co= nvey the aforementioned subtleties is proving difficult for me.
>
>
>
>
>
> On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <neil.madden@forgerock.com> = wrote:
> Right - this is what we have implemented. No support for certificate-b= ound refresh tokens, the client can be configured to require TLS cert clien= t authentication instead.
>
> Neil
>
> On 14 Mar 2019, at 08:09, Filip Skokan <panva.ip@gmail.com> wrote:
>
>> Point being that since the refresh token is only usable on the IdP= then mtls client auth already covers this, and since RTs are long-lasting,= it does this better because cert rotation is possible for both mtls method= s.
>>
>> S pozdravem,
>> Filip Skokan
>>
>>
>> On Thu, 14 Mar 2019 at 08:07, Filip Skokan <panva..ip@gmail.com> wrote: >> Even before refresh tokens were mentioned in draft 13 i was about = to implement this binding in nodejs oidc-provider,
>>
>> the thing i struggled with and ultimately didn't do this was >>
>> 1) if the refresh token is bound to a specific cert then this cert= rotation is out of the question
>> 2) if having the RT somehow covered is needed, isn't MTLS clie= nt auth already the right thing to do? Especially given it supports cert ro= tation
>>
>> Now the normative language is SHOULD therefore disallowing cert ro= tation. Or am I missing something?
>>
>> S pozdravem,
>> Filip Skokan
>>
>>
>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcampbell=3D40pingide= ntity.com@dmarc.ietf.org> wrote:
>> As I kinda said on that call, I understand the ask and I do think = it'd be reasonable to mention refresh tokens in the abstract now that t= he document does describe binding refresh tokens to the client certificate = with public clients.
>>
>> I'm struggling to see the fix as pretty easy, however, given t= he text of the abstract (copied below for ease of reference) and the conten= t and scope of the document.
>>
>> Do you think changing the first sentence to have "certificate= -bound access and refresh tokens" is sufficient (and accurate)?
>>
>> Or something more or different? In which case proposed text is alw= ays welcome.
>>
>> Abstract
>>
>>=C2=A0 =C2=A0 This document describes OAuth client authentication a= nd certificate-
>>=C2=A0 =C2=A0 bound access tokens using mutual Transport Layer Secu= rity (TLS)
>>=C2=A0 =C2=A0 authentication with X.509 certificates.=C2=A0 OAuth c= lients are provided a
>>=C2=A0 =C2=A0 mechanism for authentication to the authorization ser= ver using mutual
>>=C2=A0 =C2=A0 TLS, based on either self-signed certificates or publ= ic key
>>=C2=A0 =C2=A0 infrastructure (PKI).=C2=A0 OAuth authorization serve= rs are provided a
>>=C2=A0 =C2=A0 mechanism for binding access tokens to a client's= mutual TLS
>>=C2=A0 =C2=A0 certificate, and OAuth protected resources are provid= ed a method for
>>=C2=A0 =C2=A0 ensuring that such an access token presented to it wa= s issued to the
>>=C2=A0 =C2=A0 client presenting the token.
>>
>>
>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci <vittorio.ber= tocci=3D40a= uth0.com@dmarc.ietf.org> wrote:
>> Hi all,
>> during today's office hours call I pointed out that oauth-mtls= -13's abstract only mentions access token, although the spec does provi= de (some) guidance on=C2=A0 refresh token binding as well..
>> Although in the end implementers would do the right thing, given t= hat they have to read the spec in its entirety, having a mention of refresh= tokens in the abstract as well would make it easier for superficial reader= s to learn that the spec does address RTs as well. Refresh tokens leakage i= s one of the top concerns of the customers I deal with, and those people ra= rely read specs from cover to cover: having language in the abstract explic= itly calling out RTs might make some conversations easier.
>>
>> This is admittedly very minor, but the fix would also be pretty ea= sy,
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review= , use, distribution or disclosure by others is strictly prohibited...=C2=A0= If you have received this communication in error, please notify the sender= immediately by e-mail and delete the message and any file attachments from= your computer. Thank you._______________________________________________ >> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your = computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000474694058412651b-- From nobody Thu Mar 14 12:13:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313C112DF72 for ; Thu, 14 Mar 2019 12:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com 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 CgqEZoc9Kk3N for ; Thu, 14 Mar 2019 12:13:51 -0700 (PDT) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D798C1275F3 for ; Thu, 14 Mar 2019 12:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1552590829; bh=xj6iOIZOYG93/WVzeS+5/vuOwknCAjQr1eY9Ci5Lhag=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=PPz2TwjMk2p/wyzcHxU6Bl02eAiutJlRRl0hODRxhqk1gzDN8YkAoSDxT2ZnAW9prTUCMSv1/rT1QFc/t2XSe/CxXM9EVWTorbgGMZVi0XkzTAiN+5lRHJmO58GDTZ0m5+63EiWbRFf1fIr9+zclPj8rJAtUQpdtvuLRX7GIW/30Jh442TixkIesjbSLDo94AuNj3/Cn22S/0kW63WI46sTZQ7wv0XCWoHkmn49EW2w1GydV7HKS5Bead9AibImwWI0cyQupT4DMXKAOWzZUjay6c6nsFbdZlB+HjRl82PeV9+bka7pXHKxGLFhjrMAJtoPVuu0QM3xSFV7hncrAtg== X-YMail-OSG: 1du9eo8VM1kuizYIPjqYwSqlboCTh0uKpZt4uYrJcUmslTfDGo4dvfSWVP6Q8zu 5boAxSGm3LwoJMMqs5faU6Zp.i3zNZdI7WpQUgYRzBeBXOFYDpnitoX3zQqKjdIL32iz4NhTDh7Q L9p40omw58GpNXFbp9t0ESvB8u3yO9Ik7InP_kIFMVKw5rVAB7n4F4DGp3JuHp6Tazx8ysc8ujMl Kf71p.sle0Y_eC0CBQ4QdkvQs5K_vPcr_HXKNWfDRZg2PQZNKtrI3Msh2WBf6N5PmWVrjw5hk3Lq fktZnTIddf_O9J_IQELq.Kn27KM_cGxfiVi0qjSjUxqP5Vg0s.c9hy3_FMvIX0_F5.uh1U1LlUJP TewP_IbBm5WCzD.ULKhtZRMvCSTXneav1ZDjPoGv_aqVJroLS2nnMwb5qUTJ6x3DBZISgbqGTqJ6 4yGU.cwFZXCBK2buy0nX6U8E5vs8ZW3K8gcfbvLdkvEDOfg1MnTWPFohqmFfh7bWlqQVR9SJe3dp hwrKhYj7u4.FyE3iWAc7CjC27S9JjEw1i0sHLevQ6BQPzZlqHpPCVnnYmzfi8uC4GilJV_4uX.Su hYCBe3tUAoSVyJ8F_yD4jK2JmfFN2CAJPgucwrkmoeubfkPIkFvrLTfpW_RwO_20epnn8N9tE_dH PteWVO.lt57.D7oYAF7VcBpxJZGLnbT0kewYuI1nTmjctk3ZQx12SZ_PgJrC96V6dleQRvTNsILk 8BGJoXBkOYjAO59m8tchWsJKooJam6zsJr.PPr_lapsbKFRVwqHe2NvlK8513Ke3lcWuZtJVtmy4 peV8KaJ4oQ2IH95rwK2siJq8_2dl.8jAE.tm3tRUOdEIlRCoh0tbC7hA8Ky0UJdocIDTbDffv_t6 bgl0V_QaldppLHAY9iGPtioaLLXreahVp2238gZAAg9_cQV0N.ORVqmT91QozcFAATLVLOK_iL0v SY.FB5i0rnFT2WalmV9mjkt8ckQL.uqkDKuRCaYzEQidMxM8LPasmOuMIqS8N_zG5E2j3DmFTAPG G7NjN7JVlCM9cFQHAoB3KiukmXN6tsmPD8B0ePTWwEhGxzC8WpoLgo0u4Jf8lat0OTZPqRkBipJ8 9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Thu, 14 Mar 2019 19:13:49 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp414.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c56ed1a28c88b9b8bf53f011b910335b; Thu, 14 Mar 2019 19:13:47 +0000 (UTC) To: Brian Campbell , Neil Madden Cc: IETF oauth WG References: <5428A862-D273-42F0-8E7A-9D3FFF191F0E@forgerock.com> <41D2946C-7D10-4FF2-B5E9-D861896636AF@forgerock.com> From: George Fletcher Organization: AOL LLC Message-ID: <7c40b518-7320-f22b-90a3-e1288b6266fd@aol.com> Date: Thu, 14 Mar 2019 15:13:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A9D682E1F9DD81617BE9416F" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:13:55 -0000 This is a multi-part message in MIME format. --------------A9D682E1F9DD81617BE9416F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The one use case I've run across for introspecting refresh_tokens is to determine the lifetime of the refresh_token (i.e. when it expires). Some authorization servers bind the refresh_token to the user's authentication session and hence they have a defined lifetime. I suppose another use case might be to determine all the scopes that were issued to the refresh_token. That of course should require the correct authorization at the introspection endpoint in order to obtain the scope data:) On 3/14/19 2:50 PM, Brian Campbell wrote: > Certificate-binding refresh tokens issued to *public clients* (those > that don't have authentication credentials established with the AS, > a.k.a. clients configured or registered with the "none" authentication > method, which will typically be native apps on a phone or similar) > adds protections against malicious use or reuse of those refresh > tokens where no protections would otherwise exist. It's true that > certificate rotation in that situation would invalidate the refresh > token. But not being able to rotate a strong asymmetric credential > without invaliding the refresh token seems a very reasonable trade off > vs. not having a credential bound to the token at all. > > I guess I would say that what is returned when introspecting such a > refresh token is an implementation detail that is at the discretion of > said implementation. That seems consistent with the level of guidance > in introspection for refresh tokens currently. And there's not really > an interoperability angle that I can see. So that seems fine. Also, > some form of authorization is required to access the introspection > endpoint so I'm not sure how a refresh token issued to a public client > would realistically get introspected. I guess, if I'm being honest, I > don't really get refresh token introspection in general so probably > better that I stop opining on the subject. > > > > > > > On Thu, Mar 14, 2019 at 7:13 AM Neil Madden > wrote: > > It’s not clear to me how this works or what problem it is solving. > If a refresh token is bound to the certificate, does that mean > that a call to the introspection endpoint with that refresh token > should also return a “cnf” claim as per > https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 > ? > > It also seems problematic to implement this for refresh tokens. As > mentioned by Filip, rotation of the certificate is out of the > question. Currently in our implementation a client could present a > new certificate when using the refresh token and this would result > in the newly issued access token being bound to the new > certificate. If the refresh token is bound to the original > certificate, then this would be ruled out (the new certificate > would be rejected) and certificate rotation becomes impossible in > all cases. Am I missing something? > > — Neil > > > On 14 Mar 2019, at 12:28, Brian Campbell > > > wrote: > > > > Yeah, so regular old RFC 6749 OAuth requires that a refresh > token be bound to the client to whom it was issued. And that > confidential clients (those having established authn credentials) > authenticate to the AS when presenting a refresh token. Thus, for > both MTLS methods of OAuth client authentication, refresh tokens > are indirectly certificate-bound through their binding to a client > and its credentials (and the client rotating its cert doesn't > invalidate the refresh token). > > > > What was added in the -13 revision of the draft (in a new > section > https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) > was a brief description of certificate binding refresh tokens for > public clients. > > > > The ask from Vittorio was a mention of refresh tokens in > abstract. Which seems reasonable. But the proper wording to > succinctly and accurately convey the aforementioned subtleties is > proving difficult for me. > > > > > > > > > > > > On Thu, Mar 14, 2019 at 2:26 AM Neil Madden > > wrote: > > Right - this is what we have implemented. No support for > certificate-bound refresh tokens, the client can be configured to > require TLS cert client authentication instead. > > > > Neil > > > > On 14 Mar 2019, at 08:09, Filip Skokan > wrote: > > > >> Point being that since the refresh token is only usable on the > IdP then mtls client auth already covers this, and since RTs are > long-lasting, it does this better because cert rotation is > possible for both mtls methods. > >> > >> S pozdravem, > >> Filip Skokan > >> > >> > >> On Thu, 14 Mar 2019 at 08:07, Filip Skokan > wrote: > >> Even before refresh tokens were mentioned in draft 13 i was > about to implement this binding in nodejs oidc-provider, > >> > >> the thing i struggled with and ultimately didn't do this was > >> > >> 1) if the refresh token is bound to a specific cert then this > cert rotation is out of the question > >> 2) if having the RT somehow covered is needed, isn't MTLS > client auth already the right thing to do? Especially given it > supports cert rotation > >> > >> Now the normative language is SHOULD therefore disallowing cert > rotation. Or am I missing something? > >> > >> S pozdravem, > >> Filip Skokan > >> > >> > >> On Thu, 14 Mar 2019 at 00:21, Brian Campbell > > wrote: > >> As I kinda said on that call, I understand the ask and I do > think it'd be reasonable to mention refresh tokens in the abstract > now that the document does describe binding refresh tokens to the > client certificate with public clients. > >> > >> I'm struggling to see the fix as pretty easy, however, given > the text of the abstract (copied below for ease of reference) and > the content and scope of the document. > >> > >> Do you think changing the first sentence to have > "certificate-bound access and refresh tokens" is sufficient (and > accurate)? > >> > >> Or something more or different? In which case proposed text is > always welcome. > >> > >> Abstract > >> > >>    This document describes OAuth client authentication and > certificate- > >>    bound access tokens using mutual Transport Layer Security (TLS) > >>    authentication with X.509 certificates.  OAuth clients are > provided a > >>    mechanism for authentication to the authorization server > using mutual > >>    TLS, based on either self-signed certificates or public key > >>    infrastructure (PKI).  OAuth authorization servers are > provided a > >>    mechanism for binding access tokens to a client's mutual TLS > >>    certificate, and OAuth protected resources are provided a > method for > >>    ensuring that such an access token presented to it was > issued to the > >>    client presenting the token. > >> > >> > >> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci > > wrote: > >> Hi all, > >> during today's office hours call I pointed out that > oauth-mtls-13's abstract only mentions access token, although the > spec does provide (some) guidance on  refresh token binding as well.. > >> Although in the end implementers would do the right thing, > given that they have to read the spec in its entirety, having a > mention of refresh tokens in the abstract as well would make it > easier for superficial readers to learn that the spec does address > RTs as well. Refresh tokens leakage is one of the top concerns of > the customers I deal with, and those people rarely read specs from > cover to cover: having language in the abstract explicitly calling > out RTs might make some conversations easier. > >> > >> This is admittedly very minor, but the fix would also be pretty > easy, > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). > Any review, use, distribution or disclosure by others is strictly > prohibited...  If you have received this communication in error, > please notify the sender immediately by e-mail and delete the > message and any file attachments from your computer. Thank > you._______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). > Any review, use, distribution or disclosure by others is strictly > prohibited.  If you have received this communication in error, > please notify the sender immediately by e-mail and delete the > message and any file attachments from your computer. Thank you. > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited..  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------A9D682E1F9DD81617BE9416F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit The one use case I've run across for introspecting refresh_tokens is to determine the lifetime of the refresh_token (i.e. when it expires). Some authorization servers bind the refresh_token to the user's authentication session and hence they have a defined lifetime. I suppose another use case might be to determine all the scopes that were issued to the refresh_token. That of course should require the correct authorization at the introspection endpoint in order to obtain the scope data:)

On 3/14/19 2:50 PM, Brian Campbell wrote:
Certificate-binding refresh tokens issued to *public clients* (those that don't have authentication credentials established with the AS, a.k.a. clients configured or registered with the "none" authentication method, which will typically be native apps on a phone or similar) adds protections against malicious use or reuse of those refresh tokens where no protections would otherwise exist. It's true that certificate rotation in that situation would invalidate the refresh token. But not being able to rotate a strong asymmetric credential without invaliding the refresh token seems a very reasonable trade off vs. not having a credential bound to the token at all.

I guess I would say that what is returned when introspecting such a refresh token is an implementation detail that is at the discretion of said implementation. That seems consistent with the level of guidance in introspection for refresh tokens currently. And there's not really an interoperability angle that I can see. So that seems fine. Also, some form of authorization is required to access the introspection endpoint so I'm not sure how a refresh token issued to a public client would realistically get introspected. I guess, if I'm being honest, I don't really get refresh token introspection in general so probably better that I stop opining on the subject.






On Thu, Mar 14, 2019 at 7:13 AM Neil Madden <neil.madden@forgerock.com> wrote:
It’s not clear to me how this works or what problem it is solving. If a refresh token is bound to the certificate, does that mean that a call to the introspection endpoint with that refresh token should also return a “cnf” claim as per https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ?

It also seems problematic to implement this for refresh tokens. As mentioned by Filip, rotation of the certificate is out of the question. Currently in our implementation a client could present a new certificate when using the refresh token and this would result in the newly issued access token being bound to the new certificate. If the refresh token is bound to the original certificate, then this would be ruled out (the new certificate would be rejected) and certificate rotation becomes impossible in all cases. Am I missing something?

— Neil

> On 14 Mar 2019, at 12:28, Brian Campbell <bcampbell@pingidentity.com> wrote:
>
> Yeah, so regular old RFC 6749 OAuth requires that a refresh token be bound to the client to whom it was issued. And that confidential clients (those having established authn credentials) authenticate to the AS when presenting a refresh token. Thus, for both MTLS methods of OAuth client authentication, refresh tokens are indirectly certificate-bound through their binding to a client and its credentials (and the client rotating its cert doesn't invalidate the refresh token).
>
> What was added in the -13 revision of the draft (in a new section https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a brief description of certificate binding refresh tokens for public clients.
>
> The ask from Vittorio was a mention of refresh tokens in abstract. Which seems reasonable. But the proper wording to succinctly and accurately convey the aforementioned subtleties is proving difficult for me.
>
>
>
>
>
> On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <neil.madden@forgerock.com> wrote:
> Right - this is what we have implemented. No support for certificate-bound refresh tokens, the client can be configured to require TLS cert client authentication instead.
>
> Neil
>
> On 14 Mar 2019, at 08:09, Filip Skokan <panva.ip@gmail.com> wrote:
>
>> Point being that since the refresh token is only usable on the IdP then mtls client auth already covers this, and since RTs are long-lasting, it does this better because cert rotation is possible for both mtls methods.
>>
>> S pozdravem,
>> Filip Skokan
>>
>>
>> On Thu, 14 Mar 2019 at 08:07, Filip Skokan <panva..ip@gmail.com> wrote:
>> Even before refresh tokens were mentioned in draft 13 i was about to implement this binding in nodejs oidc-provider,
>>
>> the thing i struggled with and ultimately didn't do this was
>>
>> 1) if the refresh token is bound to a specific cert then this cert rotation is out of the question
>> 2) if having the RT somehow covered is needed, isn't MTLS client auth already the right thing to do? Especially given it supports cert rotation
>>
>> Now the normative language is SHOULD therefore disallowing cert rotation. Or am I missing something?
>>
>> S pozdravem,
>> Filip Skokan
>>
>>
>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
>> As I kinda said on that call, I understand the ask and I do think it'd be reasonable to mention refresh tokens in the abstract now that the document does describe binding refresh tokens to the client certificate with public clients.
>>
>> I'm struggling to see the fix as pretty easy, however, given the text of the abstract (copied below for ease of reference) and the content and scope of the document.
>>
>> Do you think changing the first sentence to have "certificate-bound access and refresh tokens" is sufficient (and accurate)?
>>
>> Or something more or different? In which case proposed text is always welcome.
>>
>> Abstract
>>
>>    This document describes OAuth client authentication and certificate-
>>    bound access tokens using mutual Transport Layer Security (TLS)
>>    authentication with X.509 certificates.  OAuth clients are provided a
>>    mechanism for authentication to the authorization server using mutual
>>    TLS, based on either self-signed certificates or public key
>>    infrastructure (PKI).  OAuth authorization servers are provided a
>>    mechanism for binding access tokens to a client's mutual TLS
>>    certificate, and OAuth protected resources are provided a method for
>>    ensuring that such an access token presented to it was issued to the
>>    client presenting the token.
>>
>>
>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org> wrote:
>> Hi all,
>> during today's office hours call I pointed out that oauth-mtls-13's abstract only mentions access token, although the spec does provide (some) guidance on  refresh token binding as well..
>> Although in the end implementers would do the right thing, given that they have to read the spec in its entirety, having a mention of refresh tokens in the abstract as well would make it easier for superficial readers to learn that the spec does address RTs as well. Refresh tokens leakage is one of the top concerns of the customers I deal with, and those people rarely read specs from cover to cover: having language in the abstract explicitly calling out RTs might make some conversations easier.
>>
>> This is admittedly very minor, but the fix would also be pretty easy,
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------A9D682E1F9DD81617BE9416F-- From nobody Thu Mar 14 12:49:59 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D7C13110C for ; Thu, 14 Mar 2019 12:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com 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 3swjg3x_YCmd for ; Thu, 14 Mar 2019 12:49:53 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B6D13106F for ; Thu, 14 Mar 2019 12:49:52 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id y15so7203173wro.4 for ; Thu, 14 Mar 2019 12:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HYldcbeceiDADoIbJGcK+NpuGewXJHDxi57hDDUAO8c=; b=IIA/mVZQLjBdf1Pk/CJCKavqCl1iNHA7DH+tlTIK0IAvZO5n2bxnKez6wa657PxECQ QwaC+fcdksDaN1zVFzm6jDnLpmkQUJgDWjhgKkGqAvzmqxmheQmtm22cSaWBu71ugH5+ 1Eni7mRszmfYkg5iENztd1SVmQVwSdnVgFxRo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HYldcbeceiDADoIbJGcK+NpuGewXJHDxi57hDDUAO8c=; b=c5SjQfKMCfx5pz1ftr23cS5U8AYETEV+JPU1JH6356mkz35TmrqQzSMl8o/5wbtWxY vbtDdC9D4P686cMx7QgKZVr1hX8j5eMXkqtPSynCnd2M8xbNOjyvF4RDJvj2a/9a5UbZ w3x7ceAMlZfEsotm3Jnj1c1Wro1IxpzChUOeukWCEn2QfO1Qo5FpkdvJDqS600ziL0TC PzOsOiXjWNNqhbjsSeFr2tF4QbqmYImThSjk1lWS642LJ93omzRPJ+eIh6Rs8Vs2YXT/ IEtJg9BY1QPOJD2wOYM7eH6GJ8PJImq6sEbOKIl+f7fYDMpDY227nRZCKkbQ5nGJi6+E Osow== X-Gm-Message-State: APjAAAXNyg39S1Rd6TrGPM63X2p7RyQw43/LyCtAWn5H5x0qhG0uwXdA iKW78E1QF1hl/+S79XlF9N0nFwoLPZM/+21ji5GVPbmjDX/ErpXZSuJUF++TfqCM2bBxgiKH+DP eq8cYsAvr9RyvRhDfr+UISrRyjspm0myj7T+yUR7WSoh/0iCm4NnQYSWto7YhMHI= X-Google-Smtp-Source: APXvYqzKiP2bK6lHyGVIfBXP2bxqZmE2LPXvRAEKDCEqOwz8A8TsIhHrvTMILuE9HA8bD1ukEtNvnw== X-Received: by 2002:adf:b591:: with SMTP id c17mr34806205wre.195.1552592990750; Thu, 14 Mar 2019 12:49:50 -0700 (PDT) Received: from ?IPv6:2a01:4c8:1d:1140:f82b:8d56:e0e8:2f0a? ([2a01:4c8:1d:1140:f82b:8d56:e0e8:2f0a]) by smtp.gmail.com with ESMTPSA id j184sm4492616wma.47.2019.03.14.12.49.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 12:49:49 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A990CEC7-6109-4250-800B-F4E3C70AA067 Mime-Version: 1.0 (1.0) From: Neil Madden X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Thu, 14 Mar 2019 19:49:48 +0000 Cc: Filip Skokan , IETF oauth WG Content-Transfer-Encoding: 7bit Message-Id: References: <5428A862-D273-42F0-8E7A-9D3FFF191F0E@forgerock.com> <41D2946C-7D10-4FF2-B5E9-D861896636AF@forgerock.com> To: Brian Campbell Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:49:58 -0000 --Apple-Mail-A990CEC7-6109-4250-800B-F4E3C70AA067 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Comments in-line: > On 14 Mar 2019, at 18:50, Brian Campbell wrot= e: >=20 > Certificate-binding refresh tokens issued to *public clients* (those that d= on't have authentication credentials established with the AS, a.k.a. clients= configured or registered with the "none" authentication method, which will t= ypically be native apps on a phone or similar) adds protections against mali= cious use or reuse of those refresh tokens where no protections would otherw= ise exist. Refresh tokens have a different threat model to access tokens as they are on= ly communicated directly between the client and the AS over a secure channel= . The main risk is of them being compromised on the client [*], but then a p= rivate key is at the same risk. Even if you generate the private key in a TP= M on the device (eg mobile device with secure hardware), any malicious actor= that is able to extract the refresh token from the client is also presumabl= y in a position to either proxy requests through an existing TLS connection o= n that client or else interact with the TPM to create a new one.=20 [*] Or by a compromise of TLS, but that breaks everything.=20 > It's true that certificate rotation in that situation would invalidate the= refresh token. But not being able to rotate a strong asymmetric credential w= ithout invaliding the refresh token seems a very reasonable trade off vs. no= t having a credential bound to the token at all.=20 I would not make that trade-off. If you are at OSW next week, I am presentin= g some cases for OAuth mTLS in a kubernetes environment that have public cli= ents with long-lived grants that use refresh tokens to periodically rotate c= erts.=20 > I guess I would say that what is returned when introspecting such a refres= h token is an implementation detail that is at the discretion of said implem= entation. That seems consistent with the level of guidance in introspection f= or refresh tokens currently. And there's not really an interoperability angl= e that I can see. So that seems fine. Also, some form of authorization is re= quired to access the introspection endpoint so I'm not sure how a refresh to= ken issued to a public client would realistically get introspected. I guess,= if I'm being honest, I don't really get refresh token introspection in gene= ral so probably better that I stop opining on the subject.=20 Ok, I=E2=80=99m happy to just ignore that aspect for refresh tokens then.=20= =E2=80=94 Neil >=20 >=20 >=20 >=20 >=20 >=20 >> On Thu, Mar 14, 2019 at 7:13 AM Neil Madden w= rote: >> It=E2=80=99s not clear to me how this works or what problem it is solving= . If a refresh token is bound to the certificate, does that mean that a call= to the introspection endpoint with that refresh token should also return a =E2= =80=9Ccnf=E2=80=9D claim as per https://tools.ietf.org/html/draft-ietf-oauth= -mtls-13#section-3.2 ?=20 >>=20 >> It also seems problematic to implement this for refresh tokens. As mentio= ned by Filip, rotation of the certificate is out of the question. Currently i= n our implementation a client could present a new certificate when using the= refresh token and this would result in the newly issued access token being b= ound to the new certificate. If the refresh token is bound to the original c= ertificate, then this would be ruled out (the new certificate would be rejec= ted) and certificate rotation becomes impossible in all cases. Am I missing s= omething? >>=20 >> =E2=80=94 Neil >>=20 >> > On 14 Mar 2019, at 12:28, Brian Campbell w= rote: >> >=20 >> > Yeah, so regular old RFC 6749 OAuth requires that a refresh token be bo= und to the client to whom it was issued. And that confidential clients (thos= e having established authn credentials) authenticate to the AS when presenti= ng a refresh token. Thus, for both MTLS methods of OAuth client authenticati= on, refresh tokens are indirectly certificate-bound through their binding to= a client and its credentials (and the client rotating its cert doesn't inva= lidate the refresh token). >> >=20 >> > What was added in the -13 revision of the draft (in a new section https= ://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a brief descr= iption of certificate binding refresh tokens for public clients. >> >=20 >> > The ask from Vittorio was a mention of refresh tokens in abstract. Whic= h seems reasonable. But the proper wording to succinctly and accurately conv= ey the aforementioned subtleties is proving difficult for me. >> >=20 >> >=20 >> >=20 >> >=20 >> >=20 >> > On Thu, Mar 14, 2019 at 2:26 AM Neil Madden = wrote: >> > Right - this is what we have implemented. No support for certificate-bo= und refresh tokens, the client can be configured to require TLS cert client a= uthentication instead.=20 >> >=20 >> > Neil >> >=20 >> > On 14 Mar 2019, at 08:09, Filip Skokan wrote: >> >=20 >> >> Point being that since the refresh token is only usable on the IdP the= n mtls client auth already covers this, and since RTs are long-lasting, it d= oes this better because cert rotation is possible for both mtls methods. >> >>=20 >> >> S pozdravem, >> >> Filip Skokan >> >>=20 >> >>=20 >> >> On Thu, 14 Mar 2019 at 08:07, Filip Skokan wrote= : >> >> Even before refresh tokens were mentioned in draft 13 i was about to i= mplement this binding in nodejs oidc-provider, >> >>=20 >> >> the thing i struggled with and ultimately didn't do this was >> >>=20 >> >> 1) if the refresh token is bound to a specific cert then this cert rot= ation is out of the question >> >> 2) if having the RT somehow covered is needed, isn't MTLS client auth a= lready the right thing to do? Especially given it supports cert rotation >> >>=20 >> >> Now the normative language is SHOULD therefore disallowing cert rotati= on. Or am I missing something? >> >>=20 >> >> S pozdravem, >> >> Filip Skokan >> >>=20 >> >>=20 >> >> On Thu, 14 Mar 2019 at 00:21, Brian Campbell wrote: >> >> As I kinda said on that call, I understand the ask and I do think it'd= be reasonable to mention refresh tokens in the abstract now that the docume= nt does describe binding refresh tokens to the client certificate with publi= c clients.=20 >> >>=20 >> >> I'm struggling to see the fix as pretty easy, however, given the text o= f the abstract (copied below for ease of reference) and the content and scop= e of the document.=20 >> >>=20 >> >> Do you think changing the first sentence to have "certificate-bound ac= cess and refresh tokens" is sufficient (and accurate)?=20 >> >>=20 >> >> Or something more or different? In which case proposed text is always w= elcome. >> >>=20 >> >> Abstract >> >>=20 >> >> This document describes OAuth client authentication and certificate= - >> >> bound access tokens using mutual Transport Layer Security (TLS) >> >> authentication with X.509 certificates. OAuth clients are provided= a >> >> mechanism for authentication to the authorization server using mutu= al >> >> TLS, based on either self-signed certificates or public key >> >> infrastructure (PKI). OAuth authorization servers are provided a >> >> mechanism for binding access tokens to a client's mutual TLS >> >> certificate, and OAuth protected resources are provided a method fo= r >> >> ensuring that such an access token presented to it was issued to th= e >> >> client presenting the token. >> >>=20 >> >>=20 >> >> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci wrote: >> >> Hi all, >> >> during today's office hours call I pointed out that oauth-mtls-13's ab= stract only mentions access token, although the spec does provide (some) gui= dance on refresh token binding as well..=20 >> >> Although in the end implementers would do the right thing, given that t= hey have to read the spec in its entirety, having a mention of refresh token= s in the abstract as well would make it easier for superficial readers to le= arn that the spec does address RTs as well. Refresh tokens leakage is one of= the top concerns of the customers I deal with, and those people rarely read= specs from cover to cover: having language in the abstract explicitly calli= ng out RTs might make some conversations easier. >> >>=20 >> >> This is admittedly very minor, but the fix would also be pretty easy,=20= >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >>=20 >> >> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, use= , distribution or disclosure by others is strictly prohibited... If you hav= e received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your compute= r. Thank you._______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >=20 >> > CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately by= e-mail and delete the message and any file attachments from your computer. T= hank you. >>=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rece= ived this communication in error, please notify the sender immediately by e-= mail and delete the message and any file attachments from your computer. Tha= nk you. --Apple-Mail-A990CEC7-6109-4250-800B-F4E3C70AA067 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Com= ments in-line:

On 14 Mar 2019, at 18:50, Brian Cam= pbell <bcampbell@pingidenti= ty.com> wrote:

Certificate-binding refresh tokens issued to *public clients= * (those that don't have authentication credentials established with the AS,= a.k.a. clients configured or registered with the "none" authentication meth= od, which will typically be native apps on a phone or similar) adds protecti= ons against malicious use or reuse of those refresh tokens where no protecti= ons would otherwise exist.

Refresh tokens have a different threat model to acc= ess tokens as they are only communicated directly between the client and the= AS over a secure channel. The main risk is of them being compromised on the= client [*], but then a private key is at the same risk. Even if you generat= e the private key in a TPM on the device (eg mobile device with secure hardw= are), any malicious actor that is able to extract the refresh token from the= client is also presumably in a position to either proxy requests through an= existing TLS connection on that client or else interact with the TPM to cre= ate a new one. 

[*] Or by a compromise of TLS,= but that breaks everything. 

It's true that certificate rotation in that situat= ion would invalidate the refresh token. But not being able to rotate a stron= g asymmetric credential without invaliding the refresh token seems a very re= asonable trade off vs. not having a credential bound to the token at all.

I would not make that trade-off. If you are at OSW next week, I am presenti= ng some cases for OAuth mTLS in a kubernetes environment that have public cl= ients with long-lived grants that use refresh tokens to periodically rotate c= erts. 

I guess I would say that what is returned when introspecting such a refres= h token is an implementation detail that is at the discretion of said implem= entation. That seems consistent with the level of guidance in introspection f= or refresh tokens currently. And there's not really an interoperability angl= e that I can see. So that seems fine. Also, some form of authorization is re= quired to access the introspection endpoint so I'm not sure how a refresh to= ken issued to a public client would realistically get introspected. I guess,= if I'm being honest, I don't really get refresh token introspection in gene= ral so probably better that I stop opining on the subject.
<= /div>

Ok, I=E2=80=99= m happy to just ignore that aspect for refresh tokens then. 
=
=E2=80=94 Neil







On Thu, Mar 14, 2019 at 7:13 AM Neil= Madden <n= eil.madden@forgerock.com> wrote:
It=E2=80=99s not clear to me how this works or what pr= oblem it is solving. If a refresh token is bound to the certificate, does th= at mean that a call to the introspection endpoint with that refresh token sh= ould also return a =E2=80=9Ccnf=E2=80=9D claim as per https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section= -3.2 ?

It also seems problematic to implement this for refresh tokens. As mentioned= by Filip, rotation of the certificate is out of the question. Currently in o= ur implementation a client could present a new certificate when using the re= fresh token and this would result in the newly issued access token being bou= nd to the new certificate. If the refresh token is bound to the original cer= tificate, then this would be ruled out (the new certificate would be rejecte= d) and certificate rotation becomes impossible in all cases. Am I missing so= mething?

=E2=80=94 Neil

> On 14 Mar 2019, at 12:28, Brian Campbell <bcampbell@pingidentity.com> wro= te:
>
> Yeah, so regular old RFC 6749 OAuth requires that a refresh token be bo= und to the client to whom it was issued. And that confidential clients (thos= e having established authn credentials) authenticate to the AS when presenti= ng a refresh token. Thus, for both MTLS methods of OAuth client authenticati= on, refresh tokens are indirectly certificate-bound through their binding to= a client and its credentials (and the client rotating its cert doesn't inva= lidate the refresh token).
>
> What was added in the -13 revision of the draft (in a new section https://tools.ietf.org/html/draft-ietf-oauth-= mtls-13#section-4) was a brief description of certificate binding refres= h tokens for public clients.
>
> The ask from Vittorio was a mention of refresh tokens in abstract. Whic= h seems reasonable. But the proper wording to succinctly and accurately conv= ey the aforementioned subtleties is proving difficult for me.
>
>
>
>
>
> On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <neil.madden@forgerock.com> wr= ote:
> Right - this is what we have implemented. No support for certificate-bo= und refresh tokens, the client can be configured to require TLS cert client a= uthentication instead.
>
> Neil
>
> On 14 Mar 2019, at 08:09, Filip Skokan <panva.ip@gmail.com> wrote:
>
>> Point being that since the refresh token is only usable on the IdP t= hen mtls client auth already covers this, and since RTs are long-lasting, it= does this better because cert rotation is possible for both mtls methods. >>
>> S pozdravem,
>> Filip Skokan
>>
>>
>> On Thu, 14 Mar 2019 at 08:07, Filip Skokan <panva..ip@gmail.com> wrote:
>> Even before refresh tokens were mentioned in draft 13 i was about t= o implement this binding in nodejs oidc-provider,
>>
>> the thing i struggled with and ultimately didn't do this was
>>
>> 1) if the refresh token is bound to a specific cert then this cert r= otation is out of the question
>> 2) if having the RT somehow covered is needed, isn't MTLS client au= th already the right thing to do? Especially given it supports cert rotation=
>>
>> Now the normative language is SHOULD therefore disallowing cert rot= ation. Or am I missing something?
>>
>> S pozdravem,
>> Filip Skokan
>>
>>
>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcampbell=3D40pingident= ity.com@dmarc.ietf.org> wrote:
>> As I kinda said on that call, I understand the ask and I do think i= t'd be reasonable to mention refresh tokens in the abstract now that the doc= ument does describe binding refresh tokens to the client certificate with pu= blic clients.
>>
>> I'm struggling to see the fix as pretty easy, however, given the te= xt of the abstract (copied below for ease of reference) and the content and s= cope of the document.
>>
>> Do you think changing the first sentence to have "certificate-bound= access and refresh tokens" is sufficient (and accurate)?
>>
>> Or something more or different? In which case proposed text is alwa= ys welcome.
>>
>> Abstract
>>
>>    This document describes OAuth client authentication an= d certificate-
>>    bound access tokens using mutual Transport Layer Secur= ity (TLS)
>>    authentication with X.509 certificates.  OAuth cl= ients are provided a
>>    mechanism for authentication to the authorization serv= er using mutual
>>    TLS, based on either self-signed certificates or publi= c key
>>    infrastructure (PKI).  OAuth authorization server= s are provided a
>>    mechanism for binding access tokens to a client's mutu= al TLS
>>    certificate, and OAuth protected resources are provide= d a method for
>>    ensuring that such an access token presented to it was= issued to the
>>    client presenting the token.
>>
>>
>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci <vittorio.bert= occi=3D40aut= h0.com@dmarc.ietf.org> wrote:
>> Hi all,
>> during today's office hours call I pointed out that oauth-mtls-13's= abstract only mentions access token, although the spec does provide (some) g= uidance on  refresh token binding as well..
>> Although in the end implementers would do the right thing, given th= at they have to read the spec in its entirety, having a mention of refresh t= okens in the abstract as well would make it easier for superficial readers t= o learn that the spec does address RTs as well. Refresh tokens leakage is on= e of the top concerns of the customers I deal with, and those people rarely r= ead specs from cover to cover: having language in the abstract explicitly ca= lling out RTs might make some conversations easier.
>>
>> This is admittedly very minor, but the fix would also be pretty eas= y,
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org<= /a>
>> https://www.ietf.org/mailman/listinfo/oauth >>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and pri= vileged material for the sole use of the intended recipient(s). Any review, u= se, distribution or disclosure by others is strictly prohibited...  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you._______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org<= /a>
>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org<= /a>
>> https://www.ietf.org/mailman/listinfo/oauth >
> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use,= distribution or disclosure by others is strictly prohibited.  If you h= ave received this communication in error, please notify the sender immediate= ly by e-mail and delete the message and any file attachments from your compu= ter. Thank you.


CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review,= use, distribution or disclosure by others is strictly prohibited.  If y= ou have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your c= omputer. Thank you.
= --Apple-Mail-A990CEC7-6109-4250-800B-F4E3C70AA067-- From nobody Fri Mar 15 13:56:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC681312C6 for ; Fri, 15 Mar 2019 13:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 jcoy6sJ6an7I for ; Fri, 15 Mar 2019 13:56:01 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D931312BA for ; Fri, 15 Mar 2019 13:56:01 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id l139so13027932ita.5 for ; Fri, 15 Mar 2019 13:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4n+bNT+0yvhpNe+z5S8Ho8sOyWr6R5F9eP7oNOYVGZE=; b=UxdJ9qmTNiikTBKUy5qvcczfqGDYd7S8rB5zOQsHSO7bcNpOXR6q/1KMmXHQL8YywX JN+bogSjS3oya1mcRnzWz02rsbCUmm9+bDZq1cX2neQbuckpkS765hSytv0kHVrLIfkO hZCW8J+mE/Gl/h3dxS+UMBvOUyhXMcRbnvFIU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4n+bNT+0yvhpNe+z5S8Ho8sOyWr6R5F9eP7oNOYVGZE=; b=N/L8B2mPAJ/27VsqEQbqhNJvGUHbTdcjcSystfHaGGOJwbBK90K+9hnA9fTMWOxITm GoX4ZmVCkDvQra/+o/JWj/p13vje1wV1pGbVDwTYNG911y7Rd/XnTDq4HNq/UX1PktrN W4WDFzwUCyhwVTC/VZtIEef1J/90fHpWogKXgUYNyS3/Fa832fbdNWjNM2GVscliTtIk XnlcEDP0qSp/jUrV9G61fCnrOmbw7ZSeRvI8U1itvdMPpN8645JnSPQOKerErE3DJG7F kY9L3omkJt/C1NOmQjN5NW1tC3u/Ju0xvp+NTaTeJrcAfOQGF5FMjCX4R/UM8zZKdnPk Scnw== X-Gm-Message-State: APjAAAWDBbMQLLcghoeuBpZfAl3GPeF/im7qZPPTJYAMbXTOABlHzofy CEV6/Tzov6jN24IIJzjLmMp9fteN7Nz9xQcrPfJhVauEZ1LyMrVPMGHrIl1ak1zJnvJYFu5gpvf RxZM/6HIGXephaw== X-Google-Smtp-Source: APXvYqz7GCxIJn0K0CP4ZDYvZRHNiMingUBZKrWpUfqAbyLGcXf9rI1tVURFiJQZb8C2SdMH4TPMRy2Rfr9oKDHkk9A= X-Received: by 2002:a24:2487:: with SMTP id f129mr3357912ita.124.1552683360307; Fri, 15 Mar 2019 13:56:00 -0700 (PDT) MIME-Version: 1.0 References: <5428A862-D273-42F0-8E7A-9D3FFF191F0E@forgerock.com> <41D2946C-7D10-4FF2-B5E9-D861896636AF@forgerock.com> In-Reply-To: From: Brian Campbell Date: Fri, 15 Mar 2019 14:55:34 -0600 Message-ID: To: Neil Madden Cc: Filip Skokan , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000023e9ad0584284418" Archived-At: Subject: Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 20:56:06 -0000 --00000000000023e9ad0584284418 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your point about refresh tokens having a different threat model to access tokens is taken, however, I think I'd stop short of saying a private key is always at the same risk. I will be at OSW next week and look forward to your presentation. Hopefully it'll help me better understand the threat model and goals and constraints and etc. you are working with. As far as the document is concerned, there are folks that are interested in the cert-binding of refresh tokens for public clients. So I don't it should be removed. The text in -13 has a SHOULD for it so your case of not cert-binding RTs is still within the lines of the spec. But perhaps that SHOULD can be loosened and/or qualified somewhat so as to better accommodate that case. I was trying to avoid it, but introducing a client metadata flag to toggle the RT binding behavior is also a potential option. On Thu, Mar 14, 2019 at 1:49 PM Neil Madden wrote: > Comments in-line: > > On 14 Mar 2019, at 18:50, Brian Campbell > wrote: > > Certificate-binding refresh tokens issued to *public clients* (those that > don't have authentication credentials established with the AS, a.k.a. > clients configured or registered with the "none" authentication method, > which will typically be native apps on a phone or similar) adds protectio= ns > against malicious use or reuse of those refresh tokens where no protectio= ns > would otherwise exist. > > > Refresh tokens have a different threat model to access tokens as they are > only communicated directly between the client and the AS over a secure > channel. The main risk is of them being compromised on the client [*], bu= t > then a private key is at the same risk. Even if you generate the private > key in a TPM on the device (eg mobile device with secure hardware), any > malicious actor that is able to extract the refresh token from the client > is also presumably in a position to either proxy requests through an > existing TLS connection on that client or else interact with the TPM to > create a new one. > > [*] Or by a compromise of TLS, but that breaks everything. > > It's true that certificate rotation in that situation would invalidate th= e > refresh token. But not being able to rotate a strong asymmetric credentia= l > without invaliding the refresh token seems a very reasonable trade off vs= . > not having a credential bound to the token at all. > > > I would not make that trade-off. If you are at OSW next week, I am > presenting some cases for OAuth mTLS in a kubernetes environment that hav= e > public clients with long-lived grants that use refresh tokens to > periodically rotate certs. > > I guess I would say that what is returned when introspecting such a > refresh token is an implementation detail that is at the discretion of sa= id > implementation. That seems consistent with the level of guidance in > introspection for refresh tokens currently. And there's not really an > interoperability angle that I can see. So that seems fine. Also, some for= m > of authorization is required to access the introspection endpoint so I'm > not sure how a refresh token issued to a public client would realisticall= y > get introspected. I guess, if I'm being honest, I don't really get refres= h > token introspection in general so probably better that I stop opining on > the subject. > > > Ok, I=E2=80=99m happy to just ignore that aspect for refresh tokens then. > > =E2=80=94 Neil > > > > > > > > On Thu, Mar 14, 2019 at 7:13 AM Neil Madden > wrote: > >> It=E2=80=99s not clear to me how this works or what problem it is solvin= g. If a >> refresh token is bound to the certificate, does that mean that a call to >> the introspection endpoint with that refresh token should also return a >> =E2=80=9Ccnf=E2=80=9D claim as per >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ? >> >> It also seems problematic to implement this for refresh tokens. As >> mentioned by Filip, rotation of the certificate is out of the question. >> Currently in our implementation a client could present a new certificate >> when using the refresh token and this would result in the newly issued >> access token being bound to the new certificate. If the refresh token is >> bound to the original certificate, then this would be ruled out (the new >> certificate would be rejected) and certificate rotation becomes impossib= le >> in all cases. Am I missing something? >> >> =E2=80=94 Neil >> >> > On 14 Mar 2019, at 12:28, Brian Campbell >> wrote: >> > >> > Yeah, so regular old RFC 6749 OAuth requires that a refresh token be >> bound to the client to whom it was issued. And that confidential clients >> (those having established authn credentials) authenticate to the AS when >> presenting a refresh token. Thus, for both MTLS methods of OAuth client >> authentication, refresh tokens are indirectly certificate-bound through >> their binding to a client and its credentials (and the client rotating i= ts >> cert doesn't invalidate the refresh token). >> > >> > What was added in the -13 revision of the draft (in a new section >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a >> brief description of certificate binding refresh tokens for public clien= ts. >> > >> > The ask from Vittorio was a mention of refresh tokens in abstract. >> Which seems reasonable. But the proper wording to succinctly and accurat= ely >> convey the aforementioned subtleties is proving difficult for me. >> > >> > >> > >> > >> > >> > On Thu, Mar 14, 2019 at 2:26 AM Neil Madden >> wrote: >> > Right - this is what we have implemented. No support for >> certificate-bound refresh tokens, the client can be configured to requir= e >> TLS cert client authentication instead. >> > >> > Neil >> > >> > On 14 Mar 2019, at 08:09, Filip Skokan wrote: >> > >> >> Point being that since the refresh token is only usable on the IdP >> then mtls client auth already covers this, and since RTs are long-lastin= g, >> it does this better because cert rotation is possible for both mtls meth= ods. >> >> >> >> S pozdravem, >> >> Filip Skokan >> >> >> >> >> >> On Thu, 14 Mar 2019 at 08:07, Filip Skokan >> wrote: >> >> Even before refresh tokens were mentioned in draft 13 i was about to >> implement this binding in nodejs oidc-provider, >> >> >> >> the thing i struggled with and ultimately didn't do this was >> >> >> >> 1) if the refresh token is bound to a specific cert then this cert >> rotation is out of the question >> >> 2) if having the RT somehow covered is needed, isn't MTLS client auth >> already the right thing to do? Especially given it supports cert rotatio= n >> >> >> >> Now the normative language is SHOULD therefore disallowing cert >> rotation. Or am I missing something? >> >> >> >> S pozdravem, >> >> Filip Skokan >> >> >> >> >> >> On Thu, 14 Mar 2019 at 00:21, Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >> As I kinda said on that call, I understand the ask and I do think it'= d >> be reasonable to mention refresh tokens in the abstract now that the >> document does describe binding refresh tokens to the client certificate >> with public clients. >> >> >> >> I'm struggling to see the fix as pretty easy, however, given the text >> of the abstract (copied below for ease of reference) and the content and >> scope of the document. >> >> >> >> Do you think changing the first sentence to have "certificate-bound >> access and refresh tokens" is sufficient (and accurate)? >> >> >> >> Or something more or different? In which case proposed text is always >> welcome. >> >> >> >> Abstract >> >> >> >> This document describes OAuth client authentication and certificat= e- >> >> bound access tokens using mutual Transport Layer Security (TLS) >> >> authentication with X.509 certificates. OAuth clients are provide= d >> a >> >> mechanism for authentication to the authorization server using >> mutual >> >> TLS, based on either self-signed certificates or public key >> >> infrastructure (PKI). OAuth authorization servers are provided a >> >> mechanism for binding access tokens to a client's mutual TLS >> >> certificate, and OAuth protected resources are provided a method f= or >> >> ensuring that such an access token presented to it was issued to t= he >> >> client presenting the token. >> >> >> >> >> >> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci > 40auth0.com@dmarc.ietf.org> wrote: >> >> Hi all, >> >> during today's office hours call I pointed out that oauth-mtls-13's >> abstract only mentions access token, although the spec does provide (som= e) >> guidance on refresh token binding as well.. >> >> Although in the end implementers would do the right thing, given that >> they have to read the spec in its entirety, having a mention of refresh >> tokens in the abstract as well would make it easier for superficial read= ers >> to learn that the spec does address RTs as well. Refresh tokens leakage = is >> one of the top concerns of the customers I deal with, and those people >> rarely read specs from cover to cover: having language in the abstract >> explicitly calling out RTs might make some conversations easier. >> >> >> >> This is admittedly very minor, but the fix would also be pretty easy, >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any f= ile >> attachments from your computer. Thank >> you._______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you. >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000023e9ad0584284418 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your point about refresh tokens having a different threat model t= o access tokens is taken, however, I think I'd stop short of saying a p= rivate key is always at the same risk.

I will be at OSW next week and look forward to your presentation. Hop= efully it'll help me better understand the threat model and goals and c= onstraints and etc. you are working with.

As = far as the document is concerned, there are folks that are interested in th= e cert-binding of refresh tokens for public clients. So I don't it shou= ld be removed. The text in -13 has a SHOULD for it so your case of not cert= -binding RTs is still within the lines of the spec. But perhaps that SHOULD= can be loosened and/or qualified somewhat so as to better accommodate that= case. I was trying to avoid it, but introducing a client metadata flag to = toggle the RT binding behavior is also a potential option.

On Thu, Mar 14, 2019 at 1:49 PM Neil Madden <neil.madden@forgerock.com> wrote:
=
<= div dir=3D"ltr">
Comments in-line:

On 14 Mar 2019, at 18:50, Brian Campbell <bcampbell@pingidentity.com>= ; wrote:

Certificate-binding refresh tokens issued to *public clients* (those= that don't have authentication credentials established with the AS, a.= k.a. clients configured or registered with the "none" authenticat= ion method, which will typically be native apps on a phone or similar) adds= protections against malicious use or reuse of those refresh tokens where n= o protections would otherwise exist.

Refresh tokens have a different threat = model to access tokens as they are only communicated directly between the c= lient and the AS over a secure channel. The main risk is of them being comp= romised on the client [*], but then a private key is at the same risk. Even= if you generate the private key in a TPM on the device (eg mobile device w= ith secure hardware), any malicious actor that is able to extract the refre= sh token from the client is also presumably in a position to either proxy r= equests through an existing TLS connection on that client or else interact = with the TPM to create a new one.=C2=A0

[*] Or by = a compromise of TLS, but that breaks everything.=C2=A0

It's true that certifi= cate rotation in that situation would invalidate the refresh token. But not= being able to rotate a strong asymmetric credential without invaliding the= refresh token seems a very reasonable trade off vs. not having a credentia= l bound to the token at all.
=

I would not make that trade-off. If you ar= e at OSW next week, I am presenting some cases for OAuth mTLS in a kubernet= es environment that have public clients with long-lived grants that use ref= resh tokens to periodically rotate certs.=C2=A0

I guess I would say that what is = returned when introspecting such a refresh token is an implementation detai= l that is at the discretion of said implementation. That seems consistent w= ith the level of guidance in introspection for refresh tokens currently. An= d there's not really an interoperability angle that I can see. So that = seems fine. Also, some form of authorization is required to access the intr= ospection endpoint so I'm not sure how a refresh token issued to a publ= ic client would realistically get introspected. I guess, if I'm being h= onest, I don't really get refresh token introspection in general so pro= bably better that I stop opining on the subject.

Ok, I=E2=80=99m happy = to just ignore that aspect for refresh tokens then.=C2=A0

=E2=80=94 Neil

=






<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 14, 2019 at 7:13 AM Neil M= adden <ne= il.madden@forgerock.com> wrote:
It=E2=80=99s not clear to me how this works or what = problem it is solving. If a refresh token is bound to the certificate, does= that mean that a call to the introspection endpoint with that refresh toke= n should also return a =E2=80=9Ccnf=E2=80=9D claim as per https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#= section-3.2 ?

It also seems problematic to implement this for refresh tokens. As mentione= d by Filip, rotation of the certificate is out of the question. Currently i= n our implementation a client could present a new certificate when using th= e refresh token and this would result in the newly issued access token bein= g bound to the new certificate. If the refresh token is bound to the origin= al certificate, then this would be ruled out (the new certificate would be = rejected) and certificate rotation becomes impossible in all cases. Am I mi= ssing something?

=E2=80=94 Neil

> On 14 Mar 2019, at 12:28, Brian Campbell <bcampbell@pingidentity.com> w= rote:
>
> Yeah, so regular old RFC 6749 OAuth requires that a refresh token be b= ound to the client to whom it was issued. And that confidential clients (th= ose having established authn credentials) authenticate to the AS when prese= nting a refresh token. Thus, for both MTLS methods of OAuth client authenti= cation, refresh tokens are indirectly certificate-bound through their bindi= ng to a client and its credentials (and the client rotating its cert doesn&= #39;t invalidate the refresh token).
>
> What was added in the -13 revision of the draft (in a new section https://tools.ietf.org/html/draft-ietf-oa= uth-mtls-13#section-4) was a brief description of certificate binding r= efresh tokens for public clients.
>
> The ask from Vittorio was a mention of refresh tokens in abstract. Whi= ch seems reasonable. But the proper wording to succinctly and accurately co= nvey the aforementioned subtleties is proving difficult for me.
>
>
>
>
>
> On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <neil.madden@forgerock.com> = wrote:
> Right - this is what we have implemented. No support for certificate-b= ound refresh tokens, the client can be configured to require TLS cert clien= t authentication instead.
>
> Neil
>
> On 14 Mar 2019, at 08:09, Filip Skokan <panva.ip@gmail.com> wrote:
>
>> Point being that since the refresh token is only usable on the IdP= then mtls client auth already covers this, and since RTs are long-lasting,= it does this better because cert rotation is possible for both mtls method= s.
>>
>> S pozdravem,
>> Filip Skokan
>>
>>
>> On Thu, 14 Mar 2019 at 08:07, Filip Skokan <panva..ip@gmail.com> wrote: >> Even before refresh tokens were mentioned in draft 13 i was about = to implement this binding in nodejs oidc-provider,
>>
>> the thing i struggled with and ultimately didn't do this was >>
>> 1) if the refresh token is bound to a specific cert then this cert= rotation is out of the question
>> 2) if having the RT somehow covered is needed, isn't MTLS clie= nt auth already the right thing to do? Especially given it supports cert ro= tation
>>
>> Now the normative language is SHOULD therefore disallowing cert ro= tation. Or am I missing something?
>>
>> S pozdravem,
>> Filip Skokan
>>
>>
>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcampbell=3D40pingide= ntity.com@dmarc.ietf.org> wrote:
>> As I kinda said on that call, I understand the ask and I do think = it'd be reasonable to mention refresh tokens in the abstract now that t= he document does describe binding refresh tokens to the client certificate = with public clients.
>>
>> I'm struggling to see the fix as pretty easy, however, given t= he text of the abstract (copied below for ease of reference) and the conten= t and scope of the document.
>>
>> Do you think changing the first sentence to have "certificate= -bound access and refresh tokens" is sufficient (and accurate)?
>>
>> Or something more or different? In which case proposed text is alw= ays welcome.
>>
>> Abstract
>>
>>=C2=A0 =C2=A0 This document describes OAuth client authentication a= nd certificate-
>>=C2=A0 =C2=A0 bound access tokens using mutual Transport Layer Secu= rity (TLS)
>>=C2=A0 =C2=A0 authentication with X.509 certificates.=C2=A0 OAuth c= lients are provided a
>>=C2=A0 =C2=A0 mechanism for authentication to the authorization ser= ver using mutual
>>=C2=A0 =C2=A0 TLS, based on either self-signed certificates or publ= ic key
>>=C2=A0 =C2=A0 infrastructure (PKI).=C2=A0 OAuth authorization serve= rs are provided a
>>=C2=A0 =C2=A0 mechanism for binding access tokens to a client's= mutual TLS
>>=C2=A0 =C2=A0 certificate, and OAuth protected resources are provid= ed a method for
>>=C2=A0 =C2=A0 ensuring that such an access token presented to it wa= s issued to the
>>=C2=A0 =C2=A0 client presenting the token.
>>
>>
>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci <vittorio.ber= tocci=3D40a= uth0.com@dmarc.ietf.org> wrote:
>> Hi all,
>> during today's office hours call I pointed out that oauth-mtls= -13's abstract only mentions access token, although the spec does provi= de (some) guidance on=C2=A0 refresh token binding as well..
>> Although in the end implementers would do the right thing, given t= hat they have to read the spec in its entirety, having a mention of refresh= tokens in the abstract as well would make it easier for superficial reader= s to learn that the spec does address RTs as well. Refresh tokens leakage i= s one of the top concerns of the customers I deal with, and those people ra= rely read specs from cover to cover: having language in the abstract explic= itly calling out RTs might make some conversations easier.
>>
>> This is admittedly very minor, but the fix would also be pretty ea= sy,
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review= , use, distribution or disclosure by others is strictly prohibited...=C2=A0= If you have received this communication in error, please notify the sender= immediately by e-mail and delete the message and any file attachments from= your computer. Thank you._______________________________________________ >> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your = computer. Thank you.


CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000023e9ad0584284418-- From nobody Mon Mar 18 15:44:00 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535091310B5 for ; Mon, 18 Mar 2019 15:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 TRSX3aJtXBvl for ; Mon, 18 Mar 2019 15:43:54 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1C0C213104D for ; Mon, 18 Mar 2019 15:43:54 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2IMhnWD022038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Mar 2019 18:43:51 -0400 Date: Mon, 18 Mar 2019 17:43:49 -0500 From: Benjamin Kaduk To: Brian Campbell Cc: Lars Wilhelmsen , oauth Message-ID: <20190318224348.GF80498@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 22:43:58 -0000 On Thu, Mar 14, 2019 at 06:55:38AM -0600, Brian Campbell wrote: > There are icon links for audio and video next to the sessions on the agenda > at https://datatracker.ietf.org/meeting/104/agenda/. I believe registration > is required (but is free for remote participants). See > https://www.ietf.org/how/meetings/104/remote/ for more official > information. Registration is required (AFAIK) for the live video stream (which includes an ability to get into a "virtual microphone queue", but not for the live audio stream or the jabber room. -Ben > Recordings will be available after the fact at some point on the > proceedings at https://datatracker.ietf.org/meeting/104/proceedings (here's > the the previous meeting's proceedings for example > https://datatracker.ietf.org/meeting/103/proceedings). > > On Thu, Mar 14, 2019 at 2:17 AM Lars Wilhelmsen 40Thales.no@dmarc.ietf.org> wrote: > > > Hi, > > > > > > > > Are these sessions recorded / available to follow online? > > > > > > > > Regards, > > > > --larsw > > > > > > > > *From:* OAuth *On Behalf Of *Rifaat Shekh-Yusef > > *Sent:* onsdag 13. mars 2019 18:46 > > *To:* oauth > > *Subject:* Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings > > > > > > > > Use the following links instead: > > > > https://datatracker.ietf.org/doc/agenda-104-oauth-sessa/ > > > > https://datatracker.ietf.org/doc/agenda-104-oauth-sessb/ > > > > > > > > Regards, > > > > Rifaat > > > > > > > > > > > > On Wed, Mar 13, 2019 at 1:37 PM Rifaat Shekh-Yusef > > wrote: > > > > All, > > > > > > > > The following links have our draft agenda for the two sessions: > > > > > > > > > > https://datatracker.ietf.org/meeting/104/materials/agenda-104-oauth-sessa-00 > > > > > > https://datatracker.ietf.org/meeting/104/materials/agenda-104-oauth-sessb-00 > > > > > > > > Please, take a look and let us know if you have any comments. > > > > > > > > Regards, > > > > Rifaat & Hannes > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you._ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Mar 23 09:45:56 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508E01279E6 for ; Sat, 23 Mar 2019 09:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7o5lHRso5T22 for ; Sat, 23 Mar 2019 09:45:53 -0700 (PDT) Received: from mail-vk1-xa42.google.com (mail-vk1-xa42.google.com [IPv6:2607:f8b0:4864:20::a42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2079C1277DE for ; Sat, 23 Mar 2019 09:45:53 -0700 (PDT) Received: by mail-vk1-xa42.google.com with SMTP id k64so1120317vke.1 for ; Sat, 23 Mar 2019 09:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7OdxjK7uYqNdeZNhBcs9DpjWDySXKgi4UhPezOLoTxw=; b=Nmla3Rkz4XHpEHGOClyids6A3qI46f/n3dmMDCfvfx47nmfOBYNloa8lrJd/MIS6qL jb/EkT0157jYFYXoytvtiTEAsGnUJ0vBz5xloe+MzXe7QEG1G5eXJ/IhibeuWboAIhoA GeZ902IlkEOJdsJSCocCmVDY9p625ivJGwiaSkmibO+4ZVyjZ41muj0AHJytP8jNM+Fr nk9PHUAewZ1UnoOkEtdD0imwfiX/iK+FjJfQBn2hlgDwuXnWUQUQkPJQqFIyquHFT7mR 9DOJSEuPGQfMfAt83EtfdocvZzUGufiiyBNV9cQoyvJEYFichyGKF8IReVP7hreykL1Z Svlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7OdxjK7uYqNdeZNhBcs9DpjWDySXKgi4UhPezOLoTxw=; b=Re0uH3sziLEDVaNFDhwSgYoJrt+bT0FHnegSmyB0Cg7GpqsyuuZrkG999nlSUaf1dw /bjeTko7DnSs6E2BISYDgZ0YibLGWSTIr8DUSYcEwiBr2wCoHRfkDvsRkm4S3w9kNpai 5OBEn+du3tXEtjiF6kBFjwdKN1a55ArPr9qzDnfkFHp22uI9HLwSxghd6+RixDuudVlk GaaqoC9l6oFAB4dbQ4i5PMoMObH/L/edwVghDKbxIjiP3tKabYQee41W9MTMDU2v8aeA JWesEWAf/NSUcZsCrFOGQrVdYbhF2zUSYNuFahCFn2K3H16EtUSyUID85goJ+OSZpRRR 7S4g== X-Gm-Message-State: APjAAAU7icg97dkhQNS74DfblkhK2mryeQ0aQJdrNMsknQ20CfmVOlX4 Ubo8WIVD+feDMH548nUnv5oujZgElLQaxGPwcBrDICA7 X-Google-Smtp-Source: APXvYqwhgxKQb4ceJS4NXcf9B+jjbpgRVx25cMx3Hhx/DTA0ZcMFW8G5hO9jYm4ct7uRKremYGEG2s9/yNGhJZ0ly7Y= X-Received: by 2002:a1f:6a02:: with SMTP id f2mr9072787vkc.10.1553359551888; Sat, 23 Mar 2019 09:45:51 -0700 (PDT) MIME-Version: 1.0 From: Keith Brian Tomo Date: Sat, 23 Mar 2019 09:45:45 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000004c84bf0584c5b487" Archived-At: Subject: [OAUTH-WG] is okay X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 16:45:54 -0000 --0000000000004c84bf0584c5b487 Content-Type: text/plain; charset="UTF-8" Re: --0000000000004c84bf0584c5b487 Content-Type: text/html; charset="UTF-8"
Re:
--0000000000004c84bf0584c5b487-- From nobody Sat Mar 23 09:47:45 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE86E1277DE for ; Sat, 23 Mar 2019 09:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8ZLE1FP9AM_r for ; Sat, 23 Mar 2019 09:47:42 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628D11279E6 for ; Sat, 23 Mar 2019 09:47:42 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id e15so1731586uam.3 for ; Sat, 23 Mar 2019 09:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ePZqbCWzIpZJKmR+e/XOC04AM5gx2sE5jsrp+1mF/xo=; b=JJxt52MU61heL8e9i2F2qckZoSJp/k6TViTvSYpD91F2ZARzBdhnF0v1zRN5b9zg0P 3/qausTVdp/PUaH/U4cKArkxUValcy+rY1Z61lTVf4FL6+VGkprrHOkNg4oXJZadyQHB 7BDOZ+GOPtNEoDLQFcx5i1GJFLVlXxT/JBgy5tNLz0f53Kf6EMW7WXN3x8KLYxqcwKm4 Lq+u1ebiLl8r+ZIY3tR5dp1A6b2NU4DMQyp683FU/YGZfTYovxi19UzthypLdfWlgSJd dELQWxgYba0w8xkFV1+4cTiAK5NHeZC5OyvTsYjkbsRm4R/FEyAKH/1a5fgEfgBZtwU0 zbxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ePZqbCWzIpZJKmR+e/XOC04AM5gx2sE5jsrp+1mF/xo=; b=hrTkD9oSkIhdHWvFSDhcWr/GFtY2pU1egdN7mfc5yeDNQQamhN1SUTu8gulR/QD0QI EM8gmvDvg11Qaa8qjq96wZlptA/6QNUV8E2GM4PgiRIfeGuR9utGj3/0pBYFCFDuEqao 3IO0xtwPs34vJKBlrW5i8UjmjwvSX5lO5tOL+jwRETcKml5RLcY4tKh6VLUB+bNpYYvv D1LLb91SyRcFIgvmsH74+5YZJqrPzknMCOvhgz9/WQf+Xgd18F5kCQo1P8+XfeumRm2a eo5XANh/9/BVgMujn2tGJSnR6kbK2i+OXpUrWK30Tmu9h0khW8c533HDTqPQ6E8HJ4ku yHQA== X-Gm-Message-State: APjAAAWTNc5Jq13gshjeqgh1z22+xvIUGV0WFTgVN9+ZL63MBSKuRwmY Uc4VGDS9kToDm7altrfy1+sw/tibxR6nbKb1c8dh4cwM X-Google-Smtp-Source: APXvYqxFIssBieyhDrjXgp5gOobznfrMSSsKaa+SjacLgBGm6Sv+6+aQHEjNXRtTY1GYuzfADV+a4zrdtB4T46BCr90= X-Received: by 2002:ab0:69d9:: with SMTP id u25mr9230981uaq.8.1553359660954; Sat, 23 Mar 2019 09:47:40 -0700 (PDT) MIME-Version: 1.0 From: Keith Brian Tomo Date: Sat, 23 Mar 2019 09:47:34 -0700 Message-ID: To: OAuth@ietf.org Content-Type: multipart/alternative; boundary="000000000000ccb85b0584c5bac8" Archived-At: Subject: [OAUTH-WG] is okay X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 16:47:44 -0000 --000000000000ccb85b0584c5bac8 Content-Type: text/plain; charset="UTF-8" "Re:" --000000000000ccb85b0584c5bac8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"Re:"=C2=A0=C2=A0
--000000000000ccb85b0584c5bac8-- From nobody Sun Mar 24 16:29:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD931201EA for ; Sun, 24 Mar 2019 16:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 EB8eBphtO6qJ for ; Sun, 24 Mar 2019 16:29:18 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361291201E3 for ; Sun, 24 Mar 2019 16:29:18 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id a6so4693671lfl.5 for ; Sun, 24 Mar 2019 16:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=h/Yqvah02vIA1xYz/oYNE+9ucqpYMApcFPCFo366imU=; b=BT+P5QgbIc40oXqAYgwCxKepeNcrdueGdWExICx0LGLcWNmnDueuFMVua2rjZDHAlk 7Qls8wn/9q0nN7Jr7QqZ7Po7Kx9HSsW2XvKnL3zLnW9Oi64CT62iXv2iYPXAJOni5mqF y+pPcBIpxkic7KpyYfy5CDDaUU63QzLT75YVtW7w7df5wfyIyCunDab9nEP5ZU2XKYs2 YCIuC9Ex3dmMLwDtiYq+H29wdZw5qy1XVqEWGzibmabPQDbrcJkxUQtEUNEQZDqNAzbU CguAVHX4ccpIBsLkvJvFZIJ9+7KTrb2RGAmWVvjn58iT15itstCG8w2iIPChX0miKPH8 OgwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=h/Yqvah02vIA1xYz/oYNE+9ucqpYMApcFPCFo366imU=; b=haqFJkDVF0lF68kXYqGezdC/mntDAUwGHq7RZshA+yrTmRU4rDLgC8GVtLQsV2Ghdp INyFQzteAW44RtYSRNRQKWhRaJfnNYeK4/EVxC7kqa97UlKeYsHl4fzwwB4VNWtz6QEu 9xhkxqx1gFbCz/zV5TySCLsGdJussnRJcjho2Pg6PUlSCE1n7PjWRZiV2/lykcWLk/JN CK2+C0Ms2lcL8ZTimJ/svySrxO7e6M7M0hQobGMXZvrDp1rvzUSHfA8taCw/WV30Yhbh oSIegoTDL8RCcayjlndh05EzBVBLsjD+I66HT1Y1pomco4XUUP34r/NMzMBiUlFb8E/Z GZgg== X-Gm-Message-State: APjAAAVqkf87j7YDIby6MVmx24mDV/uY+0VsWnlQpSTfnUBXqhCT1u/o F3tanwpek4ztW/LfNUhBJcJkQjE2oMZF/2hDVpCBMtjZ1f3V6w== X-Google-Smtp-Source: APXvYqyfaJo8O+wOs+NFhRoqnC/TyCxE451wfrSX0CPjR7mneUfMvFsejUhnV0Vdp9vK7/wLoS/78NMnRfqZ4CJ8s70= X-Received: by 2002:a19:9e0d:: with SMTP id h13mr10389150lfe.51.1553470155877; Sun, 24 Mar 2019 16:29:15 -0700 (PDT) MIME-Version: 1.0 Reply-To: Vittorio@auth0.com From: Vittorio Bertocci Date: Sun, 24 Mar 2019 16:29:05 -0700 Message-ID: To: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000cf7fb10584df74d1" Archived-At: Subject: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 23:29:21 -0000 --000000000000cf7fb10584df74d1 Content-Type: text/plain; charset="UTF-8" Dear all, I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments! Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual. - Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product. - I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). I studied and compared all those instances, identifying commonalities and differences. - I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip! - The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!! Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update. - On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process. I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. V. --000000000000cf7fb10584df74d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,
I just sub= mitted a draft describing a JWT profile for OAuth 2.0 access tokens. You ca= n find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-= oauth-access-token-jwt/.
I have a slot to discuss this tomorr= ow at IETF 104 (I'll be presenting remotely). I look forward for your c= omments!

Here's just a bit of backstory, i= n case you are interested in how this doc came to be. The trajectory it fol= lowed is somewhat unusual.
  • Despite OAuth2 not requiring a= ny specific format for ATs, through the years I have come across multiple p= roprietary solution using JWT for their access token. The intent and scenar= ios addressed by those solutions are mostly the same across vendors, but th= e syntax and interpretations in the implementations are different enough to= prevent developers from reusing code and skills when moving from product t= o product.
  • I asked several individuals from key products and servic= es to share with me concrete examples of their JWT access tokens (THANK YOU= Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft)= , Karl Guinness (Okta) for the tokens and explanations!).
    I stud= ied and compared all those instances, identifying commonalities and differe= nces.=C2=A0
  • I put together a presentation summarizing my findings a= nd suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertoc= ci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skoka= n on it. Thx Filip!
  • The presentation was followed up by 1.5 hours o= f unconference discussion, which was incredibly valuable to get tight-loop = feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir D= zhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there an= d contributed generously to the discussion. Thank you!!!
    Note: if you we= re at OSW2019, participated in the discussion and didn't get credited i= n the draft, my apologies: please send me a note and I'll make things r= ight at the next update.
  • On my flight back I did my best to incorpo= rate all the ideas and feedback in a draft, which will be discussed at IETF= 104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in = negotiating the mysterious syntax of the RFC format and submission process.=
I was blown away by the availability, involvement and willin= gness to invest time to get things right that everyone demonstrated in the = process. This is an amazing community.=C2=A0
V.
=
--000000000000cf7fb10584df74d1-- From nobody Sun Mar 24 21:12:53 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D93120264 for ; Sun, 24 Mar 2019 21:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KwmgTJu_s5ib for ; Sun, 24 Mar 2019 21:12:50 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEFC1202DB for ; Sun, 24 Mar 2019 21:12:50 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id i17so5421542pfo.6 for ; Sun, 24 Mar 2019 21:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3DmGs3ZCgVZ/elL/BoJq0I3bKlRTfhmW0UtZMCQwHJc=; b=YLg0pXucZ6RNTWYPLsJTlm91UJCm/rx0XYWmWvJZ76HOv0R72snBQ7yngYmbtSwcRg J7dECon8i//C0bKWmAjz5xLAmThf8KBcADaOjxCtfEDwjGNkP0TxFwonBDxj7tsRfKOP 4+MUrnAPFsAqHdHHdyYeQBhe1crzapxxCi96knm2CCtC+0IeQz6399xu7PyB+Hi4X0b6 eQBowWoPjq9rnYxieaHcLxzJAZ64+2qslTjCF0XCvjjKPTlG1zOxgVAxuFHhe14SseYK TTnGzFZsQx3sY+AW25HUboBibStlkmhiOLam43ZzBsSSf9yk+Q+DXLHk6Kdtq65ZLrLX xHww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3DmGs3ZCgVZ/elL/BoJq0I3bKlRTfhmW0UtZMCQwHJc=; b=iQkJfNwpjlFIo5s4283e7lsc888JOpk1/sKt9FzvyeKjVuQSmE5w7oB604dch+DOPY ZUBbJdfb+LYHQls0CfdxNXYLFL+nCSRld9HOq3bx1b905QBnDAANhNeAcuyymYh44AWc TLSFRgK/mJPamFF1PClld622tUJSWeKx3Ik5xtc632qg15xuxB82wuk4Ef4obKL+I+ta h6YKAFraVIxFLq7FZ7U0mOpB/sjlb5MM1I+FvJ8E84XYGSzOjevqTC+aKKqSBr2qKTds LT1xAAKo28/RVoDCckD54nTvMDkjHMnCKfGkpVbph9s2hSGJWyPDMeTQI2NZKpsHZW81 FpzA== X-Gm-Message-State: APjAAAUZLKSjpw8pWv5/WlQnMPJjvGhS88wEmpj3TxmZRFeSUyrrwsZJ udIEyvB6+k8WAuiEX9cf1Co= X-Google-Smtp-Source: APXvYqxygOs+V39CtkGhub2RiIT3xLkgWrwOd3Csnvy+3TkNeLgryrU9vqVEdVci5EKFmpvFPAAzdw== X-Received: by 2002:a63:4e64:: with SMTP id o36mr20788529pgl.213.1553487169981; Sun, 24 Mar 2019 21:12:49 -0700 (PDT) Received: from [192.168.202.202] (122x208x203x30.ap122.ftth.ucom.ne.jp. [122.208.203.30]) by smtp.gmail.com with ESMTPSA id j14sm18616612pfe.12.2019.03.24.21.12.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Mar 2019 21:12:49 -0700 (PDT) From: Nov Matake Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F64DD402-3087-44CE-9562-58376EDBE0AC" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 25 Mar 2019 13:12:45 +0900 In-Reply-To: Cc: IETF oauth WG To: Vittorio@auth0.com References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 04:12:53 -0000 --Apple-Mail=_F64DD402-3087-44CE-9562-58376EDBE0AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =10Hi Vittorio, Thanks for the good starting point of standardizing JWT-ized AT. One feedback. The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and client, in this spec. It requires those 2 types of identifiers to be unique each other in the = IdP context. I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so = that no such constraint needed. thanks nov > On Mar 25, 2019, at 8:29, Vittorio Bertocci = wrote: >=20 > Dear all, > I just submitted a draft describing a JWT profile for OAuth 2.0 access = tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ = .= > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting = remotely). I look forward for your comments! >=20 > Here's just a bit of backstory, in case you are interested in how this = doc came to be. The trajectory it followed is somewhat unusual. > Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. > I asked several individuals from key products and services to share = with me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian = (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).=20 > I studied and compared all those instances, identifying commonalities = and differences.=20 > I put together a presentation summarizing my findings and suggesting a = rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx = ) - got early feedback from Filip Skokan on it. = Thx Filip! > The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and = contributed generously to the discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and = didn't get credited in the draft, my apologies: please send me a note = and I'll make things right at the next update. > On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process. > I was blown away by the availability, involvement and willingness to = invest time to get things right that everyone demonstrated in the = process. This is an amazing community.=20 > V. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_F64DD402-3087-44CE-9562-58376EDBE0AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =10Hi= Vittorio,

Thanks = for the good starting point of standardizing JWT-ized AT.

One feedback.
The =E2=80=9Csub=E2=80=9D claim can include 2 types of = identifier, end-user and client, in this spec.
It = requires those 2 types of identifiers to be unique each other in the IdP = context.

I = prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so that = no such constraint needed.

thanks

nov

On Mar 25, 2019, at 8:29, = Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:

Dear all,
I just submitted a draft describing = a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-to= ken-jwt/.
I have a slot to discuss this = tomorrow at IETF 104 (I'll be presenting remotely). I look forward for = your comments!

Here's just a bit of backstory, in case = you are interested in how this doc came to be. The trajectory it = followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, = through the years I have come across multiple proprietary solution using = JWT for their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product.
  • I asked several individuals from key = products and services to share with me concrete examples of their JWT = access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell = (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for = the tokens and explanations!).
    I studied and = compared all those instances, identifying commonalities and = differences. 
  • I put together a presentation = summarizing my findings and suggesting a rough interoperable profile = (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/berto= cci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip = Skokan on it. Thx Filip!
  • The presentation was = followed up by 1.5 hours of unconference discussion, which was = incredibly valuable to get tight-loop feedback and incorporate new = ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten = Lodderstedt, Nat = Sakimura, Hannes Tschofenig were all there and contributed = generously to the discussion. Thank you!!!
    Note: if you = were at OSW2019, participated in the discussion and didn't get credited = in the draft, my apologies: please send me a note and I'll make things = right at the next update.
  • On my flight back I did my = best to incorporate all the ideas and feedback in a draft, which will be = discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were = all super helpful in negotiating the mysterious syntax of the RFC format = and submission process.
I was blown away by the = availability, involvement and willingness to invest time to get things = right that everyone demonstrated in the process. This is an amazing = community. 
V.
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_F64DD402-3087-44CE-9562-58376EDBE0AC-- From nobody Mon Mar 25 00:45:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD74120373; Mon, 25 Mar 2019 00:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3naqe-WzEyHN; Mon, 25 Mar 2019 00:45:17 -0700 (PDT) Received: from mail-vk1-xa44.google.com (mail-vk1-xa44.google.com [IPv6:2607:f8b0:4864:20::a44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614AD120371; Mon, 25 Mar 2019 00:45:17 -0700 (PDT) Received: by mail-vk1-xa44.google.com with SMTP id j195so1731063vkj.9; Mon, 25 Mar 2019 00:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=QyIB6aWk53YSf6XF9jzucgKIsfIcI75/gKkyGmmyF28=; b=VQPw58YOFzHNeVRDSyayWfJJoEXxg/haUfB0pjZL2nVXb9SRsVvP5xJpnbaR1vI4Zg V59y5SeX5RjS8UXh6ybxvJje1d53588LIo6UO9KInPc4JM4mNxMLJScJmKBwcE2rScJP TpCbN8j2Lh7cjsD1CzknxJzH4eAGuMWS1mhV+zKvcuJbpfYjt3ME6Dd9EdSm4NMFYa/y KSRD/faEZtbCEiuBwpd372+JfdEqKHHEfNQu4fIKHpQ6qnbOh4sKEpcvwRvBGS6RxJVN PgPEkryDjG9IC0uJwzlW0ZWOEdh3ADt5dqx96gsHcxCwvW4L+nCoJBZveekR45rCSs5p AHnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QyIB6aWk53YSf6XF9jzucgKIsfIcI75/gKkyGmmyF28=; b=Cb9OXo1n2cyMDgvi6OEid0qB8aZd7ma+kUgXcJh7n50JsNQqbT7yDotbp5sGdalRO1 rHW+yN+FUzLMn74IEP7vcCZyeCbPruPXWRV4pHjcnxfKs3wmqpkSND5UNPy03pQordLv Khm/EOvUuh6UYOVWYh9JXPty1LwPiZvN1aYqZKcNDVW0TQ5BoKbToN4+cjO8OzlDXQMB 0hPdHdHqOL2816pWC8WHnEjvwxEOhTeyvhW3tb4IsUtQFgje+vxAqxlS5/1NISNARJMk Os3EnoIRi+0FIylqyy5fGgMMugG4r9tPclc0o65UlhJZjt1SxUkRUg8d685RBbq+DdoD FuTA== X-Gm-Message-State: APjAAAXmgUOp+6IKxkTB8lzKc+EXlvc3lNaX807gCMavBD5Ech32nsWE sRFr6oKYQE/jH1Kqd+Alsd75FBC03+Vevu25DfE= X-Google-Smtp-Source: APXvYqz1ttc1qU2L8zpMLegVW4J4nFFoDa4GBSTnoxIgVZmQPmVLqh/sKkh2lyYIM3vwqWVci+VsK7uwGoXff+d+uiw= X-Received: by 2002:a1f:9991:: with SMTP id b139mr9731246vke.73.1553499916517; Mon, 25 Mar 2019 00:45:16 -0700 (PDT) MIME-Version: 1.0 From: Keith Brian Tomo Date: Mon, 25 Mar 2019 15:44:57 +0800 Message-ID: To: tlp-interest-owner@ietfa.amsl.com, apps-help@google.com, android@tizen.org, andriod@tizen.com, "e. g. Keith Brian Padilla Tomo" , legal@creativecommons.org, yo@dev.to, tlp-interest@ietf.org, tlp-interest-request@ietf.org, oauth@ietf.org, oauth-request@ietf.org Content-Type: multipart/alternative; boundary="000000000000aec7410584e662f6" Archived-At: Subject: [OAUTH-WG] Kernel version 3.18.35+ android@ubundu #2 Build number alps-mp-n0-mp2-V1_tinno6580.we.n_P181 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 07:45:19 -0000 --000000000000aec7410584e662f6 Content-Type: text/plain; charset="UTF-8" --000000000000aec7410584e662f6 Content-Type: text/html; charset="UTF-8"
--000000000000aec7410584e662f6-- From nobody Mon Mar 25 06:41:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87801203EF for ; Mon, 25 Mar 2019 06:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com 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 kxqjUMBLkq9c for ; Mon, 25 Mar 2019 06:41:19 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DEB120381 for ; Mon, 25 Mar 2019 06:41:19 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id x12so10244813qts.7 for ; Mon, 25 Mar 2019 06:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=GcH7n9LZKhrjz9Za2YHT+z8RwOzynyCghKl0w9fiSBM=; b=ITFwxWfo0f4zqwUxiAuI2HWwBwZgMBbSnwAZyUw7uj/k6zs2nF6CZNKWrKosChKY7S 5H9FJtkHjY2azw5IAquRSoFLCTu8qPi5Iw4TIIRxO4+ErFks0AY/YhbRqyIv53GcqIIB mAdbRMCDgGaNk6ndCUslIj/bjSELvgsiIAZ+vpqDjmMjyyQAXUNHP+qEkbdY3ktR4wtB DsMyCZYYP/l+J1/2Wt9l9Zg/7shiRuaJWV842Y2GeO7v3C0N2e175xXRC22w10CjRyIY Unj8EZr0FPgN8C2+AItICq7sbNP6yKpNuszyU6fDBlinZEid3Fo6q+BP/zm2rASxp/XI i09w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=GcH7n9LZKhrjz9Za2YHT+z8RwOzynyCghKl0w9fiSBM=; b=Y8M6Itk8JH9Stpv6RInGjxsa3yFiqYl9zIeAq0ZcQRSaY/0uP6mu3KevOblBSHtQI/ 4CzpKpajsGk6dkOP8o98nSG28vBuzmsDEqInsUM/M5GBxFiPNt3kulZVYbaJ5LZHJsFS iQPsazUZtGaoBZ/zWVVnK2kK+gsKMj1QvztYwcTt0JXVRPnkq+UgUbq8396fqEAldCPb +FqHfVzSjt3uxi7suLzPpU+7wPo4BfJmnb3Pojz1hGkJs2ucfaMEjqAex317uh6pI5h8 GhKNapF+QH7OT/ruRIB6M9biAZn4loB4GyuHiZa5x352LnLzuTUp+N6dc3Ej9roBf1JR PtFg== X-Gm-Message-State: APjAAAWGSUD2Verw34UQnczClStjhCLSGQ1PSiJXriM3u8+vJFxePIe2 c1VVt6b/kKFfDgX31MQ9cnI1i4SjKjKSl0dwdi2Y X-Google-Smtp-Source: APXvYqxdY6NqIFOT1JUKfyjLynD8668O86lZZKV8rfD/rUjfWiercySuyEP1SxPPEIzRvaL3qFVNrrItCPXh6NA6KvU= X-Received: by 2002:a0c:d155:: with SMTP id c21mr20291096qvh.64.1553521278424; Mon, 25 Mar 2019 06:41:18 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 25 Mar 2019 06:41:17 -0700 From: Dominick Baier In-Reply-To: References: MIME-Version: 1.0 Date: Mon, 25 Mar 2019 06:41:17 -0700 Message-ID: To: Nov Matake , vittorio@auth0.com Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000f3ad7f0584eb5b0a" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 13:41:23 -0000 --000000000000f3ad7f0584eb5b0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IMHO the sub claim should always refer to the user - and nothing else. OIDC says: "Subject - Identifier for the End-User at the Issuer." client_id should be used to identify clients. cheers Dominick On 25. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: Hi Vittorio, Thanks for the good starting point of standardizing JWT-ized AT. One feedback. The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-user= and client, in this spec. It requires those 2 types of identifiers to be unique each other in the IdP context. I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so that = no such constraint needed. thanks nov On Mar 25, 2019, at 8:29, Vittorio Bertocci < vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: Dear all, I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments! Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual. - Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for the= ir access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in th= e implementations are different enough to prevent developers from reusing code and skills when moving from product to product. - I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). I studied and compared all those instances, identifying commonalities and differences. - I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_j= wt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip! - The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!! Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update. - On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat= , Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process. I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. V. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --000000000000f3ad7f0584eb5b0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
IMHO= the sub claim should always refer to the user - and nothing else.

OIDC says:

"Subject - Ident= ifier for the End-User at the Issuer."

client_id should be used to identify clients.

cheers
Dominick

On 25= . March 2019 at 05:13:03, Nov Matake (m= atake@gmail.com) wrote:

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.
The =E2=80=9Csub=E2=80=9D claim can include 2 types of iden= tifier, end-user and client, in this spec.
It requires those 2 types of identifiers to be unique each other in the IdP context.

I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged c= ontext, so that no such constraint needed.

thanks

nov

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https:= //datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
  • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian= Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/= slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakimura, Hannes Tschofenig=C2=A0were all there and contributed generously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
  • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--000000000000f3ad7f0584eb5b0a-- From nobody Mon Mar 25 06:59:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4121204A4 for ; Mon, 25 Mar 2019 06:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.com 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 5lsHvYbydM0J for ; Mon, 25 Mar 2019 06:58:57 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B4B12047C for ; Mon, 25 Mar 2019 06:58:57 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id w30so10310469qta.8 for ; Mon, 25 Mar 2019 06:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9H/K/UTSL0R6S5jM9jXKCGnOXBRCpnCZZdgo8w6AsCo=; b=hERBfehREfNHBCgisNQEDakEg6Y+5obM+mQNhqSLqVwrnp85xYC+h+pnbA4l4Ctqc+ 5tmi0zuSLbJBliBm9tvI9YaLB1fKPIpevlCdEMaqP5MLjR4imr4pd9H6E/msqZ63nfn0 rEg843WQ3TeRbzTe4/L+2m1Ck2uWKr8lz9mJEFjpW+B1LKHj2Qq2ZJQThj9StrXdRwsh Km8Tigpgawyam9DextTipNh2YNFWECheN4VS9/iTTmc5a8sorzNNavdXzXm8pe9j1iak po6zmQhSAgji+NkMtxL1Ysom2+FTJJgMpGLNWdJXnNC9nL8BbYUpN3IQh4Qe06qATbYu 8Jlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9H/K/UTSL0R6S5jM9jXKCGnOXBRCpnCZZdgo8w6AsCo=; b=dcj4wb6DKGLnNBuge1Mg5z0YkjZ2cCBtXsaL4nvpdmubgECCc02TLnh+W9Towfb35e V9U5uNXaPg4f4XEX40B0gwNj3l+d+SlhPh4JZQjE9lBrrLy0HQDX6xWoYm5KNYB2aXLo ycp+glpK7ccQf7BJjOh2wr3OD1oCa9EZYPPz/z81CVnINVGsdxHLRjUS3PF9sP3gQOcw rfqSwkD5ixJfZ0QBLZs+LbvdvFyJoyZz6gzrjY/C66cL2lvHlYVN5uX98BTwDz9qnaR3 yniHEM0CYqbBpdgAtC/CCQBa1aNTSFJcObP/tmcb9zw/hIo2TdJrlDXXdPywMHK0X26M w3kA== X-Gm-Message-State: APjAAAU2eYr7KUCszc6og6XCG0sQrfYQx1YXyEEVF7W8/V2MaVb8fD/5 S/hnEXVmto6yb1+Eg7lK3sVzlbhrFSAb67qBMA4tpw== X-Google-Smtp-Source: APXvYqz/34gGDHlbmaIy8CUFYFSnBRHZBJinagQdA45jk+s307TRXPdAIXguiwQT5e9mvIivYjwf9vr4mNHBKV/rh3U= X-Received: by 2002:a0c:bd81:: with SMTP id n1mr19168074qvg.65.1553522336185; Mon, 25 Mar 2019 06:58:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hans Zandbelt Date: Mon, 25 Mar 2019 14:58:44 +0100 Message-ID: To: Dominick Baier Cc: Nov Matake , vittorio@auth0.com, IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000ffda550584eb9abd" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 13:59:06 -0000 --000000000000ffda550584eb9abd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token. The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: "The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific" which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users Hans. On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier wrote: > IMHO the sub claim should always refer to the user - and nothing else. > > OIDC says: > > "Subject - Identifier for the End-User at the Issuer." > > client_id should be used to identify clients. > > cheers > Dominick > > On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: > > Hi Vittorio, > > Thanks for the good starting point of standardizing JWT-ized AT. > > One feedback. > The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-us= er and client, in > this spec. > It requires those 2 types of identifiers to be unique each other in the > IdP context. > > I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so tha= t no such > constraint needed. > > thanks > > nov > > On Mar 25, 2019, at 8:29, Vittorio Bertocci < > vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: > > Dear all, > I just submitted a draft describing a JWT profile for OAuth 2.0 access > tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting > remotely). I look forward for your comments! > > Here's just a bit of backstory, in case you are interested in how this do= c > came to be. The trajectory it followed is somewhat unusual. > > - Despite OAuth2 not requiring any specific format for ATs, through > the years I have come across multiple proprietary solution using JWT f= or > their access token. The intent and scenarios addressed by those soluti= ons > are mostly the same across vendors, but the syntax and interpretations= in > the implementations are different enough to prevent developers from re= using > code and skills when moving from product to product. > - I asked several individuals from key products and services to share > with me concrete examples of their JWT access tokens (THANK YOU Domini= ck > Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian > (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). > I studied and compared all those instances, identifying commonalities > and differences. > - I put together a presentation summarizing my findings and suggesting > a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a= _jwt_profile_for_ats.pptx > > ) - got early feedback from Filip Skokan on it. Thx Filip! > - The presentation was followed up by 1.5 hours of unconference > discussion, which was incredibly valuable to get tight-loop feedback a= nd > incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov= , > Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there > and contributed generously to the discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a note = and > I'll make things right at the next update. > - On my flight back I did my best to incorporate all the ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. Rifa= at, > Hannes and above all Brian were all super helpful in negotiating the > mysterious syntax of the RFC format and submission process. > > I was blown away by the availability, involvement and willingness to > invest time to get things right that everyone demonstrated in the process= . > This is an amazing community. > V. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --000000000000ffda550584eb9abd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Without= agreeing or disagreeing: OIDC does not apply here since it is not OAuth an= d an access token is not an id_token.

<= div>"The "sub" (subject) claim identifies the principal that= is the
=C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JW= T are normally statements
=C2=A0 =C2=A0about the subject.=C2=A0 T= he subject value MUST either be scoped to be
=C2=A0 =C2=A0locally= unique in the context of the issuer or be globally unique.
=C2= =A0 =C2=A0The processing of this claim is generally application specific&qu= ot;

which kind of spells "client" in cas= e of the client credentials grant but I also do worry about Resource Server= s thinking/acting only in terms of users

Hans.

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wro= te:
IMHO the sub claim shoul= d always refer to the user - and nothing else.

OIDC says:

"Subject - Identifier for the End-Use= r at the Issuer."

clie= nt_id should be used to identify clients.

cheers
Dominick

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.
The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-user and client, in this spec.
It requires those 2 types of identifiers to be unique each other in the IdP context.

I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so that no such constraint needed.

thanks

nov

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
--000000000000ffda550584eb9abd-- From nobody Mon Mar 25 07:14:47 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C913F12040E for ; Mon, 25 Mar 2019 07:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 DpYpzGeNpvPj for ; Mon, 25 Mar 2019 07:14:42 -0700 (PDT) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3DA120407 for ; Mon, 25 Mar 2019 07:14:41 -0700 (PDT) Received: by mail-vs1-f53.google.com with SMTP id i207so5438549vsd.10 for ; Mon, 25 Mar 2019 07:14:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=movWJn8bEjFd4qT3SyKWHuuL1bFlw3Z5xgR3J3s2fMI=; b=KhT5d6PZqO8RXDYrYtPg0vhuddDsZnqXofBE7DrqHjxTL7Jl1RcFvWNqerfhBwUtoX faTxap9infWs4lvSq5gE5trRrxZ655GhLWtRraR3WFbAnO7BirPpYN4zD1c2bLzzquQS 2R5mS4rW5PQy0lJAt3aVMAoLeE4k2KV1qF7RcjnQxfZVBNxKv/i5CBbacORnnSRZkCq3 lT9bjZRgjGt0cFUt2ojYsM8jUTi+vs8zCyM4DKlK2iaOClOUlbGOff/TWNxSlO41JHA4 iuQAa0ivjTjCF27ZXcz/YhE/3hMk1x1ljaXhKJYntDAUbUNvIsc/Paue//hGPfKV+Cbu 42uA== X-Gm-Message-State: APjAAAXugcx8KP1TbLNIpVmek/daFkq6MqBzAdyp01l9FVKrz70K9n7M +mTqVZofzVKRVcTTRBeHtdY39ehbdOOfDDXDZKM3huIPfys= X-Google-Smtp-Source: APXvYqyVsGt7M8wWvilfzfZWTiXnZ+g7kHnyyYAs3rgdg+ewHRmjT6FmfLxCFbk+SFUxmUKf3nPADEI0YPvvI60NG8c= X-Received: by 2002:a67:dc8b:: with SMTP id g11mr14821829vsk.88.1553523280561; Mon, 25 Mar 2019 07:14:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pedro Igor Silva Date: Mon, 25 Mar 2019 15:14:29 +0100 Message-ID: To: Hans Zandbelt Cc: Dominick Baier , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000049f8150584ebd310" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 14:14:46 -0000 --00000000000049f8150584ebd310 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nice work Vittorio. I think the "sub" claim can also be used to reference the client (depending on the implementation may not necessarily map to the client_id). It might eventually reference the same entity as the client_id. In addition to the "sub" claim, does it make sense to explicitly have the "preferred_username" claim (section 5.1 of OpenID.Core) as OPTIONAL in Section 2.2 Data Structur= e ? Isn't this claim a quite common piece of information processed by resource servers? Regards. Pedro Igor On Mon, Mar 25, 2019 at 2:59 PM Hans Zandbelt wrote: > Without agreeing or disagreeing: OIDC does not apply here since it is not > OAuth and an access token is not an id_token. > The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: > > "The "sub" (subject) claim identifies the principal that is the > subject of the JWT. The claims in a JWT are normally statements > about the subject. The subject value MUST either be scoped to be > locally unique in the context of the issuer or be globally unique. > The processing of this claim is generally application specific" > > which kind of spells "client" in case of the client credentials grant but > I also do worry about Resource Servers thinking/acting only in terms of > users > > Hans. > > On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier > wrote: > >> IMHO the sub claim should always refer to the user - and nothing else. >> >> OIDC says: >> >> "Subject - Identifier for the End-User at the Issuer." >> >> client_id should be used to identify clients. >> >> cheers >> Dominick >> >> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >> >> Hi Vittorio, >> >> Thanks for the good starting point of standardizing JWT-ized AT. >> >> One feedback. >> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-u= ser and client, >> in this spec. >> It requires those 2 types of identifiers to be unique each other in the >> IdP context. >> >> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so th= at no such >> constraint needed. >> >> thanks >> >> nov >> >> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >> >> Dear all, >> I just submitted a draft describing a JWT profile for OAuth 2.0 access >> tokens. You can find it in >> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >> remotely). I look forward for your comments! >> >> Here's just a bit of backstory, in case you are interested in how this >> doc came to be. The trajectory it followed is somewhat unusual. >> >> - Despite OAuth2 not requiring any specific format for ATs, through >> the years I have come across multiple proprietary solution using JWT = for >> their access token. The intent and scenarios addressed by those solut= ions >> are mostly the same across vendors, but the syntax and interpretation= s in >> the implementations are different enough to prevent developers from r= eusing >> code and skills when moving from product to product. >> - I asked several individuals from key products and services to share >> with me concrete examples of their JWT access tokens (THANK YOU Domin= ick >> Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel >> Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explana= tions! >> ). >> I studied and compared all those instances, identifying commonalities >> and differences. >> - I put together a presentation summarizing my findings and >> suggesting a rough interoperable profile (slides: >> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_= a_jwt_profile_for_ats.pptx >> >> ) - got early feedback from Filip Skokan on it. Thx Filip! >> - The presentation was followed up by 1.5 hours of unconference >> discussion, which was incredibly valuable to get tight-loop feedback = and >> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvino= v, >> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >> and contributed generously to the discussion. Thank you!!! >> Note: if you were at OSW2019, participated in the discussion and >> didn't get credited in the draft, my apologies: please send me a note= and >> I'll make things right at the next update. >> - On my flight back I did my best to incorporate all the ideas and >> feedback in a draft, which will be discussed at IETF104 tomorrow. Rif= aat, >> Hannes and above all Brian were all super helpful in negotiating the >> mysterious syntax of the RFC format and submission process. >> >> I was blown away by the availability, involvement and willingness to >> invest time to get things right that everyone demonstrated in the proces= s. >> This is an amazing community. >> V. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000049f8150584ebd310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nice work Vittorio.

I think the "sub" claim can also be used to reference th= e client (depending on the implementation may not necessarily map to the cl= ient_id). It might eventually reference the same entity as the client_id.

In addition to the "sub" claim, does it m= ake sense to explicitly have the "preferred_username" claim= =C2=A0(section 5.1 of OpenID.Core)=C2= =A0as OPTIONAL in Section 2.2 Data Structure ?=C2=A0Isn't = this claim a quite common piece of information processed by resource servers?

Regards.
Pedro Igor

On Mon, Mar 25, 2019 at 2:59 PM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
Without agreeing or disagreeing:= OIDC does not apply here since it is not OAuth and an access token is not = an id_token.

&qu= ot;The "sub" (subject) claim identifies the principal that is the=
=C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are n= ormally statements
=C2=A0 =C2=A0about the subject.=C2=A0 The subj= ect value MUST either be scoped to be
=C2=A0 =C2=A0locally unique= in the context of the issuer or be globally unique.
=C2=A0 =C2= =A0The processing of this claim is generally application specific"

which kind of spells "client" in case of th= e client credentials grant but I also do worry about Resource Servers think= ing/acting only in terms of users

Hans.

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com= > wrote:
IMHO the sub cla= im should always refer to the user - and nothing else.

OIDC says:

"Subject - Identifier for the= End-User at the Issuer."

=
client_id should be used to identify clients.

=
cheers
Dominick

On 25.. March 2= 019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.
The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-user and client, in this spec.
It requires those 2 types of identifiers to be unique each other in the IdP context.

I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so that no such constraint needed.

thanks

nov

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000049f8150584ebd310-- From nobody Mon Mar 25 07:25:52 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A8612038C; Mon, 25 Mar 2019 07:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2YlcobpzJves; Mon, 25 Mar 2019 07:25:50 -0700 (PDT) Received: from mail-ua1-x941.google.com (mail-ua1-x941.google.com [IPv6:2607:f8b0:4864:20::941]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880E91203D0; Mon, 25 Mar 2019 07:25:50 -0700 (PDT) Received: by mail-ua1-x941.google.com with SMTP id r21so3022495uan.11; Mon, 25 Mar 2019 07:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+wYFhwaJB/PDVU0pU3F8T1i1/P2+oBTS62JlKIQuwQM=; b=grkbg+MOy+a+BW5e/Hc8YgI0xbV72Pdc7I1e10Q77G260w/jII9R6Uy047nGM8LiDv YsAa520dMtW/XRVoPW27y1+Lh7NyCkLmufG9H5aqb7oX7qBqs8BDGWoLWLM5dUy25p4Q ULnBdCBvGwVP+B/IGhV1euOg0xfwmctYKhstSB/9NiEVk3XgZ1aeCz69AZCKrhnE5hDS /NR4c1fwcwl0EmTwwp5X0hH3CQMHgGTvYOLlSLS5B9DTtW3EMiFXA7jq9mG7MJ2FXQue BJgwmWzW9YySX3jRvGYb8ZJWl1+tktRkP8XzhB2561No1zDyp20ykOOfQI3X+VkQpO0N V+nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+wYFhwaJB/PDVU0pU3F8T1i1/P2+oBTS62JlKIQuwQM=; b=lqmgxHaa+6JLQp7UijMCmFWOoETmjA1OKJZN+y2BtPd2cSthtwKAXIytZDN5+9iP/e RqMdAwmTTv8d+aL4FlW8asx1ggrI6oQRRR9mYR2QXd7+KCnwpvz0KlTThDoyz3sW0w/v 4PxcMkOVT0CVFg2xH9ATIRub5FDKc4Ft1+STeZEbxE0hPdismKD9oOi7ZxWy+LniZcmE NZCcvupP/hc4kPmoLbJT2Iy8f5yWGjhJnp0/SCzLCnWZF73UAjbE858a9lGzQFTr2Cc/ jNGYrYBfIzOVATCP38VTQL4QPy04uRAqJS+bi7Cc4X98pzCsIJUi8haJa3OWx3V33AZj olRQ== X-Gm-Message-State: APjAAAVerzbnz/1TN5e63iV622hHpXRAHor1OoxrDIAfYQkMzjaVnvC6 lFeaYDQEqVIrR9wxsUIueIzU8f65Xp+DCDlIOZmEStuDrx6LiA== X-Google-Smtp-Source: APXvYqyWgLyHlFbQVvdzArA8TF+yu/Nn+svpGA90CqmDzTgTLwQS3mC/mZtET1TibMRWxM2zLqb6ELVP5JTfgeoUI8s= X-Received: by 2002:a9f:3c01:: with SMTP id u1mr14598794uah.19.1553523949216; Mon, 25 Mar 2019 07:25:49 -0700 (PDT) MIME-Version: 1.0 From: Keith Brian Tomo Date: Mon, 25 Mar 2019 22:25:32 +0800 Message-ID: To: tlp-interest@ietf.org, legal@creativecommons.org, oauth@ietf.org, oauth-request@ietf.org, tlp-interest-request@ietf.org, tlp-interest-owner@ietf.org, tlp-interest-owner@ietfa.amsl.com, android@tizen.org, apps-help@google.com, andriod@tizen.com Content-Type: multipart/alternative; boundary="00000000000024a6e00584ebfba0" Archived-At: Subject: [OAUTH-WG] JWT X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 14:25:51 -0000 --00000000000024a6e00584ebfba0 Content-Type: text/plain; charset="UTF-8" JWT --00000000000024a6e00584ebfba0 Content-Type: text/html; charset="UTF-8"
JWT
--00000000000024a6e00584ebfba0-- From nobody Mon Mar 25 07:39:33 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC191203BB for ; Mon, 25 Mar 2019 07:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com 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 4HK2Ht0DzHaE for ; Mon, 25 Mar 2019 07:39:29 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A40120381 for ; Mon, 25 Mar 2019 07:39:28 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id z76so5417826qkb.12 for ; Mon, 25 Mar 2019 07:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=WXVHpveo7tOpkCiUU6NpvVBLfZcTMrATXVm/Vg8th/Q=; b=ABeSyrgZz5KK4GZYxZZOjhhxe3tZpARzdITtsDT84UwhHsSmdW99RizAJeEQIlDeSr XRPW/5e8MM4GGQrWjclLxNl6YXNLWByCdp7Lu6/MHDQOgd0xAVO5Pud2pctgwdpy1cao aZaEKv6+TFx8M4nYaCDGo48lTux3ZWX0/UVNn/chxqkVGHo4hoDWbiJJgDLv1AWhuzwW 4Efc4xO1LPy/LptOlaAba4+sattNHBZVaOfHmUzVSHuB9uHQdBd01gWpOxtwel8HMij5 5civQpi6U8cF6UIAaTtzIONBfVeFeBCsjXri6XfkOMU87PYAtCEq1xX+Z0e/hRHVG1L5 5loQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=WXVHpveo7tOpkCiUU6NpvVBLfZcTMrATXVm/Vg8th/Q=; b=OZYSSPD+4ky/WtyFXyyRcnlQEm85qA9thV70veMbgoY4Tk0C7Sl1gFA8wvcIKQscaw LMssMDNI83mj5kGEeEvqp11ExEhxdIrjcxlv0hclEZNVcAuCh17uGhXdhfJ//EPN71+2 19peOfZlvpWatwCvMBEhRJ5XTp1RGtQTY6xkuwXfO09vN91QgYxKTaBIwghD/dCLN3Sf PdlepVofXUSJgltsKv71DxtFIWag6GmUrhTG2pt6FAgzRWgK95UWWrFLsmJRYQ6TxluR 4SkgJJHDdh2WH2Z6qvugK2K5b7wgT5DepsuNwvGKrWZI/RASGMyXGqpuNCiHyjgKs+PM UFgA== X-Gm-Message-State: APjAAAVxnSx1mh+4t+BpRF98lFydMzpU3gNb1DytdrIiBAYZQOoz+p1g 7m3KboE9q3MhlqvfRA5otN/QZEOAWgMl1tAJaKUY X-Google-Smtp-Source: APXvYqwpsB8EPOcP9zSvOJpvrIvM7qfzgRKj2Y0vb6b+wPqXX9EvBtZILioRdDDVdG48vNM+WJPhYsCHXGRCJI5eOn8= X-Received: by 2002:a37:6484:: with SMTP id y126mr19578639qkb.186.1553524767758; Mon, 25 Mar 2019 07:39:27 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 25 Mar 2019 07:39:27 -0700 From: Dominick Baier In-Reply-To: References: MIME-Version: 1.0 Date: Mon, 25 Mar 2019 07:39:27 -0700 Message-ID: To: Hans Zandbelt Cc: IETF oauth WG , Nov Matake , vittorio@auth0.com Content-Type: multipart/alternative; boundary="000000000000eeb0bb0584ec2b82" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 14:39:31 -0000 --000000000000eeb0bb0584ec2b82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics. All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making thing= s more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it. In reality this leads to potential security problems - this spec has the potential to rectify the situation. Dominick On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote: Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token. The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: "The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific" which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users Hans. On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier wrote: > IMHO the sub claim should always refer to the user - and nothing else. > > OIDC says: > > "Subject - Identifier for the End-User at the Issuer." > > client_id should be used to identify clients. > > cheers > Dominick > > On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: > > Hi Vittorio, > > Thanks for the good starting point of standardizing JWT-ized AT. > > One feedback. > The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-us= er and client, in > this spec. > It requires those 2 types of identifiers to be unique each other in the > IdP context. > > I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so tha= t no such > constraint needed. > > thanks > > nov > > On Mar 25, 2019, at 8:29, Vittorio Bertocci < > vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: > > Dear all, > I just submitted a draft describing a JWT profile for OAuth 2.0 access > tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting > remotely). I look forward for your comments! > > Here's just a bit of backstory, in case you are interested in how this do= c > came to be. The trajectory it followed is somewhat unusual. > > - Despite OAuth2 not requiring any specific format for ATs, through > the years I have come across multiple proprietary solution using JWT f= or > their access token. The intent and scenarios addressed by those soluti= ons > are mostly the same across vendors, but the syntax and interpretations= in > the implementations are different enough to prevent developers from re= using > code and skills when moving from product to product. > - I asked several individuals from key products and services to share > with me concrete examples of their JWT access tokens (THANK YOU Domini= ck > Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian > (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). > I studied and compared all those instances, identifying commonalities > and differences. > - I put together a presentation summarizing my findings and suggesting > a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a= _jwt_profile_for_ats.pptx > > ) - got early feedback from Filip Skokan on it. Thx Filip! > - The presentation was followed up by 1.5 hours of unconference > discussion, which was incredibly valuable to get tight-loop feedback a= nd > incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov= , > Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there > and contributed generously to the discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a note = and > I'll make things right at the next update. > - On my flight back I did my best to incorporate all the ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. Rifa= at, > Hannes and above all Brian were all super helpful in negotiating the > mysterious syntax of the RFC format and submission process. > > I was blown away by the availability, involvement and willingness to > invest time to get things right that everyone demonstrated in the process= . > This is an amazing community. > V. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --000000000000eeb0bb0584ec2b82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Yes = I know - and I think in hindsight it was a mistake to use the same claim ty= pe for multiple semantics.

All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are maki= ng things more complicated than they need to be - in my experience almost n= o-one (that I know) does OIDC only - nor OAuth only. They always combine it= .

=
In reality this l= eads to potential security problems - this spec has the potential to rectif= y the situation.

Dominick

On 25. March 2019 at 14:58:56, Ha= ns Zandbelt (hans.zandbelt@zm= artzone.eu) wrote:


On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leas= tprivilege.com> wrote:
IMHO the sub claim should always refer to the user - and nothing else.

OIDC says:

"Subject - Identifier for the End-User at the Issuer."

client_id should be used to identify clients.

cheers
Dominick

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.
The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
It requires those 2 types of identifiers to be unique each other in the IdP context.

I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

thanks

nov
On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
--000000000000eeb0bb0584ec2b82-- From nobody Mon Mar 25 07:44:23 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A2E1203D0 for ; Mon, 25 Mar 2019 07:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.com 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 sDeqRGs1pdTW for ; Mon, 25 Mar 2019 07:44:19 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E5C1203CF for ; Mon, 25 Mar 2019 07:44:19 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id s81so5418427qke.13 for ; Mon, 25 Mar 2019 07:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bpeiqjJBLZMfTUvZ1YEWe55ooTmQlcdV9cJv/PKZzBg=; b=b24iB3Y44mAmSbGUfg9KOGizx/fS4zdw5TIgeB9NrJ67O+u/2TP0WNyWzWu8M5tv+q +WMWmf83oR6tkajHqgAJ6jFoUBXMRKaZeilxrdv7+1vm/glTfFbChlG68DYB8Zz6Ge1e cGOj+sA4JJoSSDXwqdnBhKoxmsaTW2L0wZPdDxkS+I4I0v09dHaYV6QOIPTlznp2uUIb T2aXVaI2mg4b4+o7bdp+dk4YhjpmcWizbIpdBkiIDy4XqHxl67j1OQ0J/xOyrspsZ5+5 S6xDeowwS1hcsejgmh0PhUXysdt9d6ZigSjogb98bYn5bi9lRiWMXUkTlgsIaTBWsrbT zoIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bpeiqjJBLZMfTUvZ1YEWe55ooTmQlcdV9cJv/PKZzBg=; b=V+7+bVUQ6kR+uVyhM/0tCowUKItow/jMNVJZ6M4+fqm+YBC0sbhDyQOTAfMXlVgW97 LpFmbXGneBtY0WVQrlfNI8tfQ4pICjT3jqMScWE9D03AG83jvqMcsjmtc9yISweBwfZy Keiti5F0FjS3ST2FZqckE4RLjMTZooqxvc4ovnH+nc0qxn/zYNgKAg7Lcp59wqMZR7ls wdTWktxyzVA+I+EtkXWRpRqtPiQl4FKrN7a3ny2LgJuChpl15xMGVqWyE2AqlA52IjTX 0qmz24kMUTBREH1ZYVPa8NXMixthcaXSNaLx3jYhNUJK86Tle05N5O24Wnnwm0XAd48Y 9XqA== X-Gm-Message-State: APjAAAXKmdEEl+/urL8Ca1BnORESwq83cyrfrCsauDhNYl2kCy6X60sy TmC40L054nmEEhaO6jifw5UYAcpL+7oGHkp0PrB2cUoC X-Google-Smtp-Source: APXvYqyXsJ2nDllUgAHQ+e6WZ41yGJ1mNX5ErcbtqnpchLTZPEQdJSmXeL57/qYfc16iEmeAOV1NmEGs402aCpM8usQ= X-Received: by 2002:a37:9acc:: with SMTP id c195mr19161337qke.106.1553525058186; Mon, 25 Mar 2019 07:44:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hans Zandbelt Date: Mon, 25 Mar 2019 15:44:06 +0100 Message-ID: To: Dominick Baier Cc: IETF oauth WG , Nov Matake , vittorio@auth0.com Content-Type: multipart/alternative; boundary="0000000000003e73080584ec3da9" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 14:44:22 -0000 --0000000000003e73080584ec3da9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same). Hans. On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier wrote: > Yes I know - and I think in hindsight it was a mistake to use the same > claim type for multiple semantics. > > All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making thi= ngs more > complicated than they need to be - in my experience almost no-one (that I > know) does OIDC only - nor OAuth only. They always combine it. > > In reality this leads to potential security problems - this spec has the > potential to rectify the situation. > > Dominick > > On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) > wrote: > > Without agreeing or disagreeing: OIDC does not apply here since it is not > OAuth and an access token is not an id_token. > The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: > > "The "sub" (subject) claim identifies the principal that is the > subject of the JWT. The claims in a JWT are normally statements > about the subject. The subject value MUST either be scoped to be > locally unique in the context of the issuer or be globally unique. > The processing of this claim is generally application specific" > > which kind of spells "client" in case of the client credentials grant but > I also do worry about Resource Servers thinking/acting only in terms of > users > > Hans. > > On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier > wrote: > >> IMHO the sub claim should always refer to the user - and nothing else. >> >> OIDC says: >> >> "Subject - Identifier for the End-User at the Issuer." >> >> client_id should be used to identify clients. >> >> cheers >> Dominick >> >> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >> >> Hi Vittorio, >> >> Thanks for the good starting point of standardizing JWT-ized AT. >> >> One feedback. >> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-u= ser and client, >> in this spec. >> It requires those 2 types of identifiers to be unique each other in the >> IdP context. >> >> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so th= at no such >> constraint needed. >> >> thanks >> >> nov >> >> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >> >> Dear all, >> I just submitted a draft describing a JWT profile for OAuth 2.0 access >> tokens. You can find it in >> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >> remotely). I look forward for your comments! >> >> Here's just a bit of backstory, in case you are interested in how this >> doc came to be. The trajectory it followed is somewhat unusual. >> >> - Despite OAuth2 not requiring any specific format for ATs, through >> the years I have come across multiple proprietary solution using JWT = for >> their access token. The intent and scenarios addressed by those solut= ions >> are mostly the same across vendors, but the syntax and interpretation= s in >> the implementations are different enough to prevent developers from r= eusing >> code and skills when moving from product to product. >> - I asked several individuals from key products and services to share >> with me concrete examples of their JWT access tokens (THANK YOU Domin= ick >> Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel >> Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explana= tions! >> ). >> I studied and compared all those instances, identifying commonalities >> and differences. >> - I put together a presentation summarizing my findings and >> suggesting a rough interoperable profile (slides: >> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_= a_jwt_profile_for_ats.pptx >> >> ) - got early feedback from Filip Skokan on it. Thx Filip! >> - The presentation was followed up by 1.5 hours of unconference >> discussion, which was incredibly valuable to get tight-loop feedback = and >> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvino= v, >> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >> and contributed generously to the discussion. Thank you!!! >> Note: if you were at OSW2019, participated in the discussion and >> didn't get credited in the draft, my apologies: please send me a note= and >> I'll make things right at the next update. >> - On my flight back I did my best to incorporate all the ideas and >> feedback in a draft, which will be discussed at IETF104 tomorrow. Rif= aat, >> Hannes and above all Brian were all super helpful in negotiating the >> mysterious syntax of the RFC format and submission process. >> >> I was blown away by the availability, involvement and willingness to >> invest time to get things right that everyone demonstrated in the proces= s. >> This is an amazing community. >> V. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --0000000000003e73080584ec3da9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe there are plenty of OAuth 2.0 o= nly use cases out there... but nevertheless I agree with the potential conf= usion and thus security problems arising from that (though one may argue th= e semantics are the same).

Hans.
=
On Mon= , Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
Yes I know - and I think in hindsight it was a = mistake to use the same claim type for multiple semantics.

All the =E2=80=9Cthis is OIDC not = OAuth=E2=80=9D arguments are making things more complicated than they need = to be - in my experience almost no-one (that I know) does OIDC only - nor O= Auth only. They always combine it.

In reality this leads to potential security problems - this= spec has the potential to rectify the situation.

Domi= nick
<= br>

On 25. March 2019 at = 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.

"The "sub" (subject) claim identifies the principal tha= t is the
=C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are normally statements
=C2=A0 =C2=A0about the subject.=C2=A0 The subject value MUST either be scoped to be
=C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
=C2=A0 =C2=A0The processing of this claim is generally application specific"

which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

Hans.

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
IMHO the sub claim should always refer to the user - and nothing else.

OIDC says:

"Subject - Identifier for the End-User at the Issuer."

client_id should be used to identify clients.

cheers
Dominick

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.
The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
It requires those 2 types of identifiers to be unique each other in the IdP context.

I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

thanks

nov
On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--


--
--0000000000003e73080584ec3da9-- From nobody Mon Mar 25 07:55:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E431203EE for ; Mon, 25 Mar 2019 07:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wavestone.com 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 fvLIYntphIJX for ; Mon, 25 Mar 2019 07:55:43 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40063.outbound.protection.outlook.com [40.107.4.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD701203A2 for ; Mon, 25 Mar 2019 07:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wavestone.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A9feF462hoidmF4SoSKpBU3hSGIro9siqD7CSgFJjx8=; b=KwkDgrlAho0eljtYCjTEnGz6b6mnu2ISnNKHGpwGiETpRaypO9as0gIqjxiPJIdYpzuGE1pwd44YLjyVD/G2SsnR62kRXVJXUWp5DAtegkBTPbyL7yb4LgHiBM83Y+dfKy1dmuaJeT8RglEVNd3Lg269CPUHGzqWS268OuE6zP4= Received: from AM6PR03MB4982.eurprd03.prod.outlook.com (20.178.89.219) by AM6PR03MB3751.eurprd03.prod.outlook.com (52.134.115.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Mon, 25 Mar 2019 14:55:39 +0000 Received: from AM6PR03MB4982.eurprd03.prod.outlook.com ([fe80::d8c6:2966:2252:5cb7]) by AM6PR03MB4982.eurprd03.prod.outlook.com ([fe80::d8c6:2966:2252:5cb7%3]) with mapi id 15.20.1730.019; Mon, 25 Mar 2019 14:55:39 +0000 From: CARLIER Bertrand To: "Vittorio@auth0.com" , IETF oauth WG Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 Thread-Index: AQHU4plzBwFW/2HF0keIgXKSbKvp56YccDLg Date: Mon, 25 Mar 2019 14:55:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bertrand.CARLIER@wavestone.com; x-originating-ip: [165.225.77.30] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 603ce0f4-a75e-4aaa-64cb-08d6b131f20f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM6PR03MB3751; x-ms-traffictypediagnostic: AM6PR03MB3751: x-microsoft-antispam-prvs: x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39860400002)(376002)(366004)(396003)(189003)(199004)(26244003)(2501003)(11346002)(110136005)(105586002)(476003)(256004)(966005)(8936002)(446003)(14454004)(478600001)(72206003)(5024004)(14444005)(486006)(316002)(68736007)(33656002)(106356001)(53936002)(97736004)(66066001)(7736002)(305945005)(71200400001)(26005)(71190400001)(5660300002)(53946003)(2906002)(6246003)(52536014)(25786009)(76176011)(74316002)(229853002)(99286004)(86362001)(7696005)(6116002)(3846002)(55016002)(102836004)(9686003)(6306002)(186003)(6506007)(30864003)(55236004)(81166006)(8676002)(81156014)(6436002)(45080400002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR03MB3751; H:AM6PR03MB4982.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: wavestone.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: oQNtAP+101E4IFmOvnjKRU/ozoTPPI3nJ75X79+IwrD5i/8OfPG1Y1Ln0mYoeaQ5DzzNqecEjOIPwGO5SIzBpb8ZKwy2pXfRINpJwzLBWPK9JusJUfb3CNAx3X750jnrkG8d44UmpdSW8kaoCl8Lgi7ExdV/KQvzO+vvHwrnf61f+fW8+LaK3W/xyunsw7hui31G6/6SCOm+HLsN03O+ZvC98rDdxaBCNJ6HP82ZdD+XGTH9+2HQHciuwxeyIIgxXzQ835mkHY7pCAmn/cBvgJovsXUitv6K1ct3SztNft5pUIzeDcXFI9WjGeQFDaoilZCqpOZOHbvQBR0a0EMvzK/J7oGXn6HGLMM+rBQOUE4cszjoXEU3S2RrmX1wMSOQMmEFaCb6SgXlCVMSDK5vrX5l52eIRKtdlhQe+WaXH4w= Content-Type: multipart/alternative; boundary="_000_AM6PR03MB4982DAE6A7A56E29DD604000875E0AM6PR03MB4982eurp_" MIME-Version: 1.0 X-OriginatorOrg: wavestone.com X-MS-Exchange-CrossTenant-Network-Message-Id: 603ce0f4-a75e-4aaa-64cb-08d6b131f20f X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 14:55:39.1752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5de96c96-c87c-4dce-aad9-f5c557b52ac1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR03MB3751 Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 14:55:47 -0000 --_000_AM6PR03MB4982DAE6A7A56E29DD604000875E0AM6PR03MB4982eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVml0dG9yaW8sDQoNClZlcnkgbmljZSB3b3JrICENCg0KSGVyZSBhcmUgYSBmZXcgaWRlYXM6 DQotIEluIGFkZGl0aW9uIHRvIHRoZSAic3ViIiBjbGFpbSAoSSBhZ3JlZSBpdCBzaG91bGQgb25s eSByZWxhdGUgdG8gdGhlIGVuZCB1c2VyLCBub3QgdGhlIGNsaWVudF9pZCksIEkgdGhpbmsgdGhl IHNjb3BlIGNsYWltIHNob3VsZCBiZSBtZW50aW9uZWQgYXMgT1BUSU9OQUwgaW4gwqcyLjIgKGl0 J3MgYWxyZWFkeSBtZW50aW9uZWQgaW4gb3RoZXIgcGFydHMgb2YgdGhlIGRyYWZ0KQ0KLSBTaG91 bGQgd2UgbWVudGlvbiBzZWN1cml0eSByZWNvbW1lbmRhdGlvbiBvbiB0aGUgSldUIChsaWtlIERP IE5PVCBVU0UgYWxnPSJub25lIikgYW5kIG1heWJlIHJlZmVyIHRvIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwLTAyLmh0bWwgPw0KLSBTaG91bGQgd2Ug bWVudGlvbiB0aGUgImFjdCIgY2xhaW0gZGVmaW5lZCBieSBUb2tlbiBFeGNoYW5nZSBhcyBhIHBv c3NpYmxlIGNsYWltIGZvciBKV1QgYWNjZXNzIHRva2Vucz8NCi0gYW55IHJlYXNvbiB0byByZWx5 IG9uIFJGQyA3NjYyIChJbnRyb3NwZWN0aW9uKSBmb3IgdGhlIHRva2VuIGZvcm1hdD8gSSBzZWUg dGhhdCB0aGUgIm5iZiIgKG5vdCBiZWZvcmUpIGNsYWltIGlzIGRlZmluZWQgdGhlcmUNCg0KUmVn YXJkcywNCi0tDQpCZXJ0cmFuZCBDQVJMSUVSDQoNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBWaXR0b3JpbyBCZXJ0b2NjaQ0KU2VudDogbHVuZGkg MjUgbWFycyAyMDE5IDAwOjI5DQpUbzogSUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbT0FVVEgtV0ddIGRyYWZ0LWJlcnRvY2NpLW9hdXRoLWFjY2Vzcy10b2tlbi1qd3Qt MDANCg0KRGVhciBhbGwsDQpJIGp1c3Qgc3VibWl0dGVkIGEgZHJhZnQgZGVzY3JpYmluZyBhIEpX VCBwcm9maWxlIGZvciBPQXV0aCAyLjAgYWNjZXNzIHRva2Vucy4gWW91IGNhbiBmaW5kIGl0IGlu IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRoLWFj Y2Vzcy10b2tlbi1qd3QvLg0KSSBoYXZlIGEgc2xvdCB0byBkaXNjdXNzIHRoaXMgdG9tb3Jyb3cg YXQgSUVURiAxMDQgKEknbGwgYmUgcHJlc2VudGluZyByZW1vdGVseSkuIEkgbG9vayBmb3J3YXJk IGZvciB5b3VyIGNvbW1lbnRzIQ0KDQpIZXJlJ3MganVzdCBhIGJpdCBvZiBiYWNrc3RvcnksIGlu IGNhc2UgeW91IGFyZSBpbnRlcmVzdGVkIGluIGhvdyB0aGlzIGRvYyBjYW1lIHRvIGJlLiBUaGUg dHJhamVjdG9yeSBpdCBmb2xsb3dlZCBpcyBzb21ld2hhdCB1bnVzdWFsLg0K4oCiICAgICAgIERl c3BpdGUgT0F1dGgyIG5vdCByZXF1aXJpbmcgYW55IHNwZWNpZmljIGZvcm1hdCBmb3IgQVRzLCB0 aHJvdWdoIHRoZSB5ZWFycyBJIGhhdmUgY29tZSBhY3Jvc3MgbXVsdGlwbGUgcHJvcHJpZXRhcnkg c29sdXRpb24gdXNpbmcgSldUIGZvciB0aGVpciBhY2Nlc3MgdG9rZW4uIFRoZSBpbnRlbnQgYW5k IHNjZW5hcmlvcyBhZGRyZXNzZWQgYnkgdGhvc2Ugc29sdXRpb25zIGFyZSBtb3N0bHkgdGhlIHNh bWUgYWNyb3NzIHZlbmRvcnMsIGJ1dCB0aGUgc3ludGF4IGFuZCBpbnRlcnByZXRhdGlvbnMgaW4g dGhlIGltcGxlbWVudGF0aW9ucyBhcmUgZGlmZmVyZW50IGVub3VnaCB0byBwcmV2ZW50IGRldmVs b3BlcnMgZnJvbSByZXVzaW5nIGNvZGUgYW5kIHNraWxscyB3aGVuIG1vdmluZyBmcm9tIHByb2R1 Y3QgdG8gcHJvZHVjdC4NCuKAoiAgICAgICBJIGFza2VkIHNldmVyYWwgaW5kaXZpZHVhbHMgZnJv bSBrZXkgcHJvZHVjdHMgYW5kIHNlcnZpY2VzIHRvIHNoYXJlIHdpdGggbWUgY29uY3JldGUgZXhh bXBsZXMgb2YgdGhlaXIgSldUIGFjY2VzcyB0b2tlbnMgKFRIQU5LIFlPVSBEb21pbmljayBCYWll ciAoSWRlbnRpdHlTZXJ2ZXIpLCBCcmlhbiBDYW1wYmVsbCAoUGluZ0lkZW50aXR5KSwgRGFuaWVs IERvYmFsaWFuIChNaWNyb3NvZnQpLCBLYXJsIEd1aW5uZXNzIChPa3RhKSBmb3IgdGhlIHRva2Vu cyBhbmQgZXhwbGFuYXRpb25zISkuDQpJIHN0dWRpZWQgYW5kIGNvbXBhcmVkIGFsbCB0aG9zZSBp bnN0YW5jZXMsIGlkZW50aWZ5aW5nIGNvbW1vbmFsaXRpZXMgYW5kIGRpZmZlcmVuY2VzLg0K4oCi ICAgICAgIEkgcHV0IHRvZ2V0aGVyIGEgcHJlc2VudGF0aW9uIHN1bW1hcml6aW5nIG15IGZpbmRp bmdzIGFuZCBzdWdnZXN0aW5nIGEgcm91Z2ggaW50ZXJvcGVyYWJsZSBwcm9maWxlIChzbGlkZXM6 IGh0dHBzOi8vc2VjLnVuaS1zdHV0dGdhcnQuZGUvX21lZGlhL2V2ZW50cy9vc3cyMDE5L3NsaWRl cy9iZXJ0b2NjaV8tX2Ffand0X3Byb2ZpbGVfZm9yX2F0cy5wcHR4PGh0dHBzOi8vc2VjLi51bmkt c3R1dHRnYXJ0LmRlL19tZWRpYS9ldmVudHMvb3N3MjAxOS9zbGlkZXMvYmVydG9jY2lfLV9hX2p3 dF9wcm9maWxlX2Zvcl9hdHMucHB0eD4gKSAtIGdvdCBlYXJseSBmZWVkYmFjayBmcm9tIEZpbGlw IFNrb2thbiBvbiBpdC4gVGh4IEZpbGlwIQ0K4oCiICAgICAgIFRoZSBwcmVzZW50YXRpb24gd2Fz IGZvbGxvd2VkIHVwIGJ5IDEuNSBob3VycyBvZiB1bmNvbmZlcmVuY2UgZGlzY3Vzc2lvbiwgd2hp Y2ggd2FzIGluY3JlZGlibHkgdmFsdWFibGUgdG8gZ2V0IHRpZ2h0LWxvb3AgZmVlZGJhY2sgYW5k IGluY29ycG9yYXRlIG5ldyBpZGVhcy4gSm9obiBCcmFkbGV5LCBCcmlhbiBDYW1wYmVsbCBWbGFk aW1pciBEemh1dmlub3YsIFRvcnN0ZW4gTG9kZGVyc3RlZHQsIE5hdCBTYWtpbXVyYSwgSGFubmVz IFRzY2hvZmVuaWcgd2VyZSBhbGwgdGhlcmUgYW5kIGNvbnRyaWJ1dGVkIGdlbmVyb3VzbHkgdG8g dGhlIGRpc2N1c3Npb24uIFRoYW5rIHlvdSEhIQ0KTm90ZTogaWYgeW91IHdlcmUgYXQgT1NXMjAx OSwgcGFydGljaXBhdGVkIGluIHRoZSBkaXNjdXNzaW9uIGFuZCBkaWRuJ3QgZ2V0IGNyZWRpdGVk IGluIHRoZSBkcmFmdCwgbXkgYXBvbG9naWVzOiBwbGVhc2Ugc2VuZCBtZSBhIG5vdGUgYW5kIEkn bGwgbWFrZSB0aGluZ3MgcmlnaHQgYXQgdGhlIG5leHQgdXBkYXRlLg0K4oCiICAgICAgIE9uIG15 IGZsaWdodCBiYWNrIEkgZGlkIG15IGJlc3QgdG8gaW5jb3Jwb3JhdGUgYWxsIHRoZSBpZGVhcyBh bmQgZmVlZGJhY2sgaW4gYSBkcmFmdCwgd2hpY2ggd2lsbCBiZSBkaXNjdXNzZWQgYXQgSUVURjEw NCB0b21vcnJvdy4gUmlmYWF0LCBIYW5uZXMgYW5kIGFib3ZlIGFsbCBCcmlhbiB3ZXJlIGFsbCBz dXBlciBoZWxwZnVsIGluIG5lZ290aWF0aW5nIHRoZSBteXN0ZXJpb3VzIHN5bnRheCBvZiB0aGUg UkZDIGZvcm1hdCBhbmQgc3VibWlzc2lvbiBwcm9jZXNzLg0KSSB3YXMgYmxvd24gYXdheSBieSB0 aGUgYXZhaWxhYmlsaXR5LCBpbnZvbHZlbWVudCBhbmQgd2lsbGluZ25lc3MgdG8gaW52ZXN0IHRp bWUgdG8gZ2V0IHRoaW5ncyByaWdodCB0aGF0IGV2ZXJ5b25lIGRlbW9uc3RyYXRlZCBpbiB0aGUg cHJvY2Vzcy4gVGhpcyBpcyBhbiBhbWF6aW5nIGNvbW11bml0eS4NClYuDQoNClRoZSBpbmZvcm1h dGlvbiB0cmFuc21pdHRlZCBpbiB0aGUgcHJlc2VudCBlbWFpbCBpbmNsdWRpbmcgdGhlIGF0dGFj aG1lbnQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiB0byB3aG9tIG9yIGVudGl0eSB0 byB3aGljaCBpdCBpcyBhZGRyZXNzZWQgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQv b3IgcHJpdmlsZWdlZCBtYXRlcmlhbC4gQW55IHJldmlldywgcmV0cmFuc21pc3Npb24sIGRpc3Nl bWluYXRpb24gb3Igb3RoZXIgdXNlIG9mLCBvciB0YWtpbmcgb2YgYW55IGFjdGlvbiBpbiByZWxp YW5jZSB1cG9uIHRoaXMgaW5mb3JtYXRpb24gYnkgcGVyc29ucyBvciBlbnRpdGllcyBvdGhlciB0 aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmVk IHRoaXMgaW4gZXJyb3IsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwg Y29waWVzIG9mIHRoZSBtYXRlcmlhbC4NCg0KQ2UgbWVzc2FnZSBldCB0b3V0ZXMgbGVzIHBpw6hj ZXMgcXVpIHkgc29udCDDqXZlbnR1ZWxsZW1lbnQgam9pbnRlcyBzb250IGNvbmZpZGVudGllbHMg ZXQgdHJhbnNtaXMgw6AgbCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNvbiBkZXN0aW5hdGFpcmUu IFRvdXRlIG1vZGlmaWNhdGlvbiwgw6lkaXRpb24sIHV0aWxpc2F0aW9uIG91IGRpZmZ1c2lvbiBw YXIgdG91dGUgcGVyc29ubmUgb3UgZW50aXTDqSBhdXRyZSBxdWUgbGUgZGVzdGluYXRhaXJlIGVz dCBpbnRlcmRpdGUuIFNpIHZvdXMgYXZleiByZcOndSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIG5v dXMgdm91cyByZW1lcmNpb25zIGRlIG5vdXMgZW4gaW5mb3JtZXIgaW1tw6lkaWF0ZW1lbnQgZXQg ZGUgbGUgc3VwcHJpbWVyIGFpbnNpIHF1ZSBsZXMgcGnDqGNlcyBxdWkgeSBzb250IMOpdmVudHVl bGxlbWVudCBqb2ludGVzLg0K --_000_AM6PR03MB4982DAE6A7A56E29DD604000875E0AM6PR03MB4982eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SGkgVml0dG9yaW8sPC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj5WZXJ5IG5pY2Ugd29yayZuYnNwOyEgPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5IZXJlIGFyZSBhIGZldyBpZGVhczo8L2Rpdj4NCjxkaXY+LSBJbiBhZGRpdGlv biB0byB0aGUgJnF1b3Q7c3ViJnF1b3Q7IGNsYWltIChJIGFncmVlIGl0IHNob3VsZCBvbmx5IHJl bGF0ZSB0byB0aGUgZW5kIHVzZXIsIG5vdCB0aGUgY2xpZW50X2lkKSwgSSB0aGluayB0aGUgc2Nv cGUgY2xhaW0gc2hvdWxkIGJlIG1lbnRpb25lZCBhcyBPUFRJT05BTCBpbiDCpzIuMiAoaXQncyBh bHJlYWR5IG1lbnRpb25lZCBpbiBvdGhlciBwYXJ0cyBvZiB0aGUgZHJhZnQpPC9kaXY+DQo8ZGl2 Pi0gU2hvdWxkIHdlIG1lbnRpb24gc2VjdXJpdHkgcmVjb21tZW5kYXRpb24gb24gdGhlIEpXVCAo bGlrZSBETyBOT1QgVVNFIGFsZz0mcXVvdDtub25lJnF1b3Q7KSBhbmQgbWF5YmUgcmVmZXIgdG8g PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW9hdXRoLWp3dC1i Y3AtMDIuaHRtbCI+PGZvbnQgY29sb3I9ImJsdWUiPjx1Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtaWV0Zi1vYXV0aC1qd3QtYmNwLTAyLmh0bWw8L3U+PC9mb250PjwvYT4NCj88L2Rp dj4NCjxkaXY+LSBTaG91bGQgd2UgbWVudGlvbiB0aGUgJnF1b3Q7YWN0JnF1b3Q7IGNsYWltIGRl ZmluZWQgYnkgVG9rZW4gRXhjaGFuZ2UgYXMgYSBwb3NzaWJsZSBjbGFpbSBmb3IgSldUIGFjY2Vz cyB0b2tlbnM/PC9kaXY+DQo8ZGl2Pi0gYW55IHJlYXNvbiB0byByZWx5IG9uIFJGQyA3NjYyIChJ bnRyb3NwZWN0aW9uKSBmb3IgdGhlIHRva2VuIGZvcm1hdD8gSSBzZWUgdGhhdCB0aGUgJnF1b3Q7 bmJmJnF1b3Q7IChub3QgYmVmb3JlKSBjbGFpbSBpcyBkZWZpbmVkIHRoZXJlPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUYWhv bWEiIHNpemU9IjIiIGNvbG9yPSIjQ0ZDRkNGIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDsi Pi0tPGJyPg0KDQo8Zm9udCBjb2xvcj0iIzUwMzA3OCI+PGI+QmVydHJhbmQgQ0FSTElFUjxicj4N Cg0KPC9iPjwvZm9udD48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzAw NDc3RiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Yj5Gcm9tOjwvYj4gT0F1dGggJmx0O29h dXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+Vml0dG9yaW8gQmVy dG9jY2k8YnI+DQoNCjxiPlNlbnQ6PC9iPiBsdW5kaSAyNSBtYXJzIDIwMTkgMDA6Mjk8YnI+DQoN CjxiPlRvOjwvYj4gSUVURiBvYXV0aCBXRyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KDQo8 Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBkcmFmdC1iZXJ0b2NjaS1vYXV0aC1hY2Nlc3MtdG9r ZW4tand0LTAwPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5EZWFyIGFsbCw8L2Rpdj4N CjxkaXY+SSBqdXN0IHN1Ym1pdHRlZCBhIGRyYWZ0IGRlc2NyaWJpbmcgYSBKV1QgcHJvZmlsZSBm b3IgT0F1dGggMi4wIGFjY2VzcyB0b2tlbnMuIFlvdSBjYW4gZmluZCBpdCBpbiZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRo LWFjY2Vzcy10b2tlbi1qd3QvIj48Zm9udCBjb2xvcj0iYmx1ZSI+PHU+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC88 L3U+PC9mb250PjwvYT4uPC9kaXY+DQo8ZGl2PkkgaGF2ZSBhIHNsb3QgdG8gZGlzY3VzcyB0aGlz IHRvbW9ycm93IGF0IElFVEYgMTA0IChJJ2xsIGJlIHByZXNlbnRpbmcgcmVtb3RlbHkpLiBJIGxv b2sgZm9yd2FyZCBmb3IgeW91ciBjb21tZW50cyE8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PkhlcmUncyBqdXN0IGEgYml0IG9mIGJhY2tzdG9yeSwgaW4gY2FzZSB5b3UgYXJlIGludGVy ZXN0ZWQgaW4gaG93IHRoaXMgZG9jIGNhbWUgdG8gYmUuIFRoZSB0cmFqZWN0b3J5IGl0IGZvbGxv d2VkIGlzIHNvbWV3aGF0IHVudXN1YWwuPC9kaXY+DQo8dWwgc3R5bGU9Im1hcmdpbjowO3BhZGRp bmctbGVmdDozNnB0OyI+DQo8bGkgc3R5bGU9Im1hcmdpbi10b3A6NXB0O21hcmdpbi1ib3R0b206 NXB0OyI+RGVzcGl0ZSBPQXV0aDIgbm90IHJlcXVpcmluZyBhbnkgc3BlY2lmaWMgZm9ybWF0IGZv ciBBVHMsIHRocm91Z2ggdGhlIHllYXJzIEkgaGF2ZSBjb21lIGFjcm9zcyBtdWx0aXBsZSBwcm9w cmlldGFyeSBzb2x1dGlvbiB1c2luZyBKV1QgZm9yIHRoZWlyIGFjY2VzcyB0b2tlbi4gVGhlIGlu dGVudCBhbmQgc2NlbmFyaW9zIGFkZHJlc3NlZCBieSB0aG9zZSBzb2x1dGlvbnMNCmFyZSBtb3N0 bHkgdGhlIHNhbWUgYWNyb3NzIHZlbmRvcnMsIGJ1dCB0aGUgc3ludGF4IGFuZCBpbnRlcnByZXRh dGlvbnMgaW4gdGhlIGltcGxlbWVudGF0aW9ucyBhcmUgZGlmZmVyZW50IGVub3VnaCB0byBwcmV2 ZW50IGRldmVsb3BlcnMgZnJvbSByZXVzaW5nIGNvZGUgYW5kIHNraWxscyB3aGVuIG1vdmluZyBm cm9tIHByb2R1Y3QgdG8gcHJvZHVjdC48L2xpPjxsaSBzdHlsZT0ibWFyZ2luLXRvcDo1cHQ7bWFy Z2luLWJvdHRvbTo1cHQ7Ij5JIGFza2VkIHNldmVyYWwgaW5kaXZpZHVhbHMgZnJvbSBrZXkgcHJv ZHVjdHMgYW5kIHNlcnZpY2VzIHRvIHNoYXJlIHdpdGggbWUgY29uY3JldGUgZXhhbXBsZXMgb2Yg dGhlaXIgSldUIGFjY2VzcyB0b2tlbnMgKFRIQU5LIFlPVSBEb21pbmljayBCYWllciAoSWRlbnRp dHlTZXJ2ZXIpLCZuYnNwOzxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBw dDsiPkJyaWFuDQpDYW1wYmVsbCAoUGluZ0lkZW50aXR5KSwgRGFuaWVsIERvYmFsaWFuIChNaWNy b3NvZnQpLCBLYXJsIEd1aW5uZXNzIChPa3RhKSBmb3IgdGhlIHRva2VucyBhbmQgZXhwbGFuYXRp b25zITwvc3Bhbj48L2ZvbnQ+KS4NCjxicj4NCg0KSSBzdHVkaWVkIGFuZCBjb21wYXJlZCBhbGwg dGhvc2UgaW5zdGFuY2VzLCBpZGVudGlmeWluZyBjb21tb25hbGl0aWVzIGFuZCBkaWZmZXJlbmNl cy4mbmJzcDs8L2xpPjxsaSBzdHlsZT0ibWFyZ2luLXRvcDo1cHQ7bWFyZ2luLWJvdHRvbTo1cHQ7 Ij5JIHB1dCB0b2dldGhlciBhIHByZXNlbnRhdGlvbiBzdW1tYXJpemluZyBteSBmaW5kaW5ncyBh bmQgc3VnZ2VzdGluZyBhIHJvdWdoIGludGVyb3BlcmFibGUgcHJvZmlsZSAoc2xpZGVzOiA8YSBo cmVmPSJodHRwczovL3NlYy4udW5pLXN0dXR0Z2FydC5kZS9fbWVkaWEvZXZlbnRzL29zdzIwMTkv c2xpZGVzL2JlcnRvY2NpXy1fYV9qd3RfcHJvZmlsZV9mb3JfYXRzLnBwdHgiPjxmb250IGNvbG9y PSJibHVlIj48dT5odHRwczovL3NlYy51bmktc3R1dHRnYXJ0LmRlL19tZWRpYS9ldmVudHMvb3N3 MjAxOS9zbGlkZXMvYmVydG9jY2lfLV9hX2p3dF9wcm9maWxlX2Zvcl9hdHMucHB0eDwvdT48L2Zv bnQ+PC9hPg0KKSAtIGdvdCBlYXJseSBmZWVkYmFjayBmcm9tIEZpbGlwIFNrb2thbiBvbiBpdC4g VGh4IEZpbGlwITwvbGk+PGxpIHN0eWxlPSJtYXJnaW4tdG9wOjVwdDttYXJnaW4tYm90dG9tOjVw dDsiPlRoZSBwcmVzZW50YXRpb24gd2FzIGZvbGxvd2VkIHVwIGJ5IDEuNSBob3VycyBvZiB1bmNv bmZlcmVuY2UgZGlzY3Vzc2lvbiwgd2hpY2ggd2FzIGluY3JlZGlibHkgdmFsdWFibGUgdG8gZ2V0 IHRpZ2h0LWxvb3AgZmVlZGJhY2sgYW5kIGluY29ycG9yYXRlIG5ldyBpZGVhcy4gSm9obiBCcmFk bGV5LCBCcmlhbiBDYW1wYmVsbCBWbGFkaW1pciBEemh1dmlub3YsIFRvcnN0ZW4NCkxvZGRlcnN0 ZWR0LDxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPiZuYnNwO05h dCBTYWtpbXVyYSwgSGFubmVzIFRzY2hvZmVuaWc8L3NwYW4+PC9mb250PiZuYnNwO3dlcmUgYWxs IHRoZXJlIGFuZCBjb250cmlidXRlZCBnZW5lcm91c2x5IHRvIHRoZSBkaXNjdXNzaW9uLiBUaGFu ayB5b3UhISE8YnI+DQoNCk5vdGU6IGlmIHlvdSB3ZXJlIGF0IE9TVzIwMTksIHBhcnRpY2lwYXRl ZCBpbiB0aGUgZGlzY3Vzc2lvbiBhbmQgZGlkbid0IGdldCBjcmVkaXRlZCBpbiB0aGUgZHJhZnQs IG15IGFwb2xvZ2llczogcGxlYXNlIHNlbmQgbWUgYSBub3RlIGFuZCBJJ2xsIG1ha2UgdGhpbmdz IHJpZ2h0IGF0IHRoZSBuZXh0IHVwZGF0ZS48L2xpPjxsaSBzdHlsZT0ibWFyZ2luLXRvcDo1cHQ7 bWFyZ2luLWJvdHRvbTo1cHQ7Ij5PbiBteSBmbGlnaHQgYmFjayBJIGRpZCBteSBiZXN0IHRvIGlu Y29ycG9yYXRlIGFsbCB0aGUgaWRlYXMgYW5kIGZlZWRiYWNrIGluIGEgZHJhZnQsIHdoaWNoIHdp bGwgYmUgZGlzY3Vzc2VkIGF0IElFVEYxMDQgdG9tb3Jyb3cuIFJpZmFhdCwgSGFubmVzIGFuZCBh Ym92ZSBhbGwgQnJpYW4gd2VyZSBhbGwgc3VwZXIgaGVscGZ1bCBpbiBuZWdvdGlhdGluZyB0aGUg bXlzdGVyaW91cw0Kc3ludGF4IG9mIHRoZSBSRkMgZm9ybWF0IGFuZCBzdWJtaXNzaW9uIHByb2Nl c3MuPC9saT48L3VsPg0KPGRpdj5JIHdhcyBibG93biBhd2F5IGJ5IHRoZSBhdmFpbGFiaWxpdHks IGludm9sdmVtZW50IGFuZCB3aWxsaW5nbmVzcyB0byBpbnZlc3QgdGltZSB0byBnZXQgdGhpbmdz IHJpZ2h0IHRoYXQgZXZlcnlvbmUgZGVtb25zdHJhdGVkIGluIHRoZSBwcm9jZXNzLiBUaGlzIGlz IGFuIGFtYXppbmcgY29tbXVuaXR5LiZuYnNwOzwvZGl2Pg0KPGRpdj5WLjwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGFob21hIiBzaXplPSIxIiBjb2xvcj0iZ3Jh eSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo1cHQ7Ij5UaGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0 ZWQgaW4gdGhlIHByZXNlbnQgZW1haWwgaW5jbHVkaW5nIHRoZSBhdHRhY2htZW50IGlzIGludGVu ZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gdG8gd2hvbSBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMg YWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yDQpwcml2aWxlZ2Vk IG1hdGVyaWFsLiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBv dGhlciB1c2Ugb2YsIG9yIHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24gdGhp cyBpbmZvcm1hdGlvbiBieSBwZXJzb25zIG9yIGVudGl0aWVzIG90aGVyIHRoYW4gdGhlIGludGVu ZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBpbiBlcnJv ciwgcGxlYXNlIGNvbnRhY3QgdGhlDQpzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRo ZSBtYXRlcmlhbC4gPGJyPg0KDQo8YnI+DQoNCkNlIG1lc3NhZ2UgZXQgdG91dGVzIGxlcyBwacOo Y2VzIHF1aSB5IHNvbnQgw6l2ZW50dWVsbGVtZW50IGpvaW50ZXMgc29udCBjb25maWRlbnRpZWxz IGV0IHRyYW5zbWlzIMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzb24gZGVzdGluYXRhaXJl LiBUb3V0ZSBtb2RpZmljYXRpb24sIMOpZGl0aW9uLCB1dGlsaXNhdGlvbiBvdSBkaWZmdXNpb24g cGFyIHRvdXRlIHBlcnNvbm5lIG91IGVudGl0w6kgYXV0cmUgcXVlIGxlIGRlc3RpbmF0YWlyZSBl c3QgaW50ZXJkaXRlLg0KU2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg bm91cyB2b3VzIHJlbWVyY2lvbnMgZGUgbm91cyBlbiBpbmZvcm1lciBpbW3DqWRpYXRlbWVudCBl dCBkZSBsZSBzdXBwcmltZXIgYWluc2kgcXVlIGxlcyBwacOoY2VzIHF1aSB5IHNvbnQgw6l2ZW50 dWVsbGVtZW50IGpvaW50ZXMuPGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIyIiBj b2xvcj0iYmxhY2siPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiA8L3NwYW4+PC9mb250 Pjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM6PR03MB4982DAE6A7A56E29DD604000875E0AM6PR03MB4982eurp_-- From nobody Mon Mar 25 08:29:54 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 370961203EB; Mon, 25 Mar 2019 08:29:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: draft-ietf-oauth-jwt-bcp@ietf.org, ekr@rtfm.com, Hannes Tschofenig , oauth@ietf.org, hannes.tschofenig@arm.com, oauth-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155352778618.28984.3417845365296464992.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2019 08:29:46 -0700 Archived-At: Subject: [OAUTH-WG] Last Call: (JSON Web Token Best Current Practices) to Best Current Practice X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 15:29:47 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'JSON Web Token Best Current Practices' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8037: CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) (Proposed Standard - IETF stream) rfc6979: Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) (Informational - Independent Submission Editor stream) rfc7516: JSON Web Encryption (JWE) (Proposed Standard - IETF stream) rfc7515: JSON Web Signature (JWS) (Proposed Standard - IETF stream) rfc7519: JSON Web Token (JWT) (Proposed Standard - IETF stream) rfc7518: JSON Web Algorithms (JWA) (Proposed Standard - IETF stream) From nobody Mon Mar 25 09:00:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B396912040B; Mon, 25 Mar 2019 09:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pkP-8L_0oFFZ; Mon, 25 Mar 2019 09:00:13 -0700 (PDT) Received: from mail-vk1-xa43.google.com (mail-vk1-xa43.google.com [IPv6:2607:f8b0:4864:20::a43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D3B120420; Mon, 25 Mar 2019 09:00:12 -0700 (PDT) Received: by mail-vk1-xa43.google.com with SMTP id l17so2067738vke.7; Mon, 25 Mar 2019 09:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JVh68JtSKqJvVppMAcMWlAWus0ipieaYrj276RzZpuU=; b=u1VgzMjLnyeValzqq4HMPhKEBjWUf58MYGd91Om/h+9O1AOLud88o2Tryna1PD9kct iKioMp5vlEVgz6GiPKUyxRS5kHVRWCpIK64Y/Egp31G6ovtH/x9olOZdJGiqilL6qkyn oqXeZCSkGh/4IGgVEoVVIlIN1oz+CKaPtE4Rqs2/Jl7DuLjML4v+StUTPqMDL5xOoWkn QqFITHQD46NlRW6wRwj+iqHPGg2HLt4/xonLqnPuqYZuchPBt1uPvz6GrFZMfKvIfRQG cix4UP9iBLKEE+GCBBKZg/LvrmYr8eH9fwUrTJ6r7e8VNCgvhoGpEovqGi9j9b9Uw9i9 enBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JVh68JtSKqJvVppMAcMWlAWus0ipieaYrj276RzZpuU=; b=VMSePxfJPI9ilaiSoLqE4mRjw8s4pBpaybNFZWN0ubd/u0AARZBZbbykIoXdv2LUVS iLsfsBj6VPX6EZdTokdoougpeLkLsHoJRE10usmRXX1KY6QdKetK5cBtPe+Gl+CCDvvh dqi2wjEaE1SG5x7ITskP5eE8MJGV8r0HTMY10yZOily+AdsH61Cn5y2kTHxN5+teN6oH ruHfBCC1aW2eedUrlYmOEnwg3mx+dkqhDWDXE0IMfDXN5lfNNCgwlrNPPecHdrjeyN9Q gjGS1h466L4hJQ5ldfEwS+Fn0vFoRNb4APlU/FSAh3fSNmmk8FbDr+/wZGCDKFpWP0rp h4Ug== X-Gm-Message-State: APjAAAXoEp6Ie99GxJ1YLsYREyDsGI5mKOQK5cLb4wVshHL7lHUs/y89 WwJTsa86jJVxCq1FEMdjcHPNBf2Zstc4oKEJKrcL8TDnUusw8Q== X-Google-Smtp-Source: APXvYqwHY8qS1wbR3mKP8Qw7QUO5HNwUBn9LN4RewqBIqLSrKS0WdB5BGJ1yv7vhwq5y76Kxpf5dM+uQegdEnQy7wYc= X-Received: by 2002:a1f:c288:: with SMTP id s130mr15289130vkf.0.1553529611147; Mon, 25 Mar 2019 09:00:11 -0700 (PDT) MIME-Version: 1.0 From: Keith Brian Tomo Date: Mon, 25 Mar 2019 23:59:58 +0800 Message-ID: To: tlp-interest@ietf.org, legal@creativecommons.org, tlp-interest-owner@ietfa.amsl.com, oauth-request@ietf.org, oauth@ietf.org, tlp-interest-owner@ietf.org, tlp-interest-request@ietf.org, android@tizen.org Content-Type: multipart/alternative; boundary="0000000000009edfb00584ed4cc4" Archived-At: Subject: [OAUTH-WG] e.g., bad password X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 16:00:15 -0000 --0000000000009edfb00584ed4cc4 Content-Type: text/plain; charset="UTF-8" e.g., bad password --0000000000009edfb00584ed4cc4 Content-Type: text/html; charset="UTF-8"
e.g., bad password
--0000000000009edfb00584ed4cc4-- From nobody Mon Mar 25 09:40:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987B71203FF; Mon, 25 Mar 2019 09:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1bODcOpgmJlH; Mon, 25 Mar 2019 09:40:09 -0700 (PDT) Received: from mail-ua1-x944.google.com (mail-ua1-x944.google.com [IPv6:2607:f8b0:4864:20::944]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6029E120412; Mon, 25 Mar 2019 09:40:09 -0700 (PDT) Received: by mail-ua1-x944.google.com with SMTP id c6so3231246uan.1; Mon, 25 Mar 2019 09:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Mk9BUpDj+1/W/HPbYPcs/0UcgK5JhQ+QqA+q7eExlh0=; b=bL8vJ55qdElJeENvUpVnpauveqhcaMrHALhkfluu5ppZDpT7kgNff+NEcj2HQ/hwvr qSMRE4ea19s4Z7+EHLPl2j3TBkPF2exzTTUmorXONjFexe3mg6y4Zsu60yqvkIaXCjVT 4RE1Ng8g4FwlBqTZO1qwRoR8ZmU61fG6JbAjcG+75aWxgCpZBJI1RKyJaG1GqExpi4zi vJC7x9UVQO9yYK+JK74oqT0gKvAc8/M5xpJRdXHwfmgAl89urvoQbJAtOnhS/YoKjwFE m+aLVSLu8OQ0ZOZcrdmhvKpTTubUV4zpb/Vo6JcpoLw0lryKk98RYwvlgkM5IwtMbyXB pmXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Mk9BUpDj+1/W/HPbYPcs/0UcgK5JhQ+QqA+q7eExlh0=; b=eAojXqIPTygLW1Bff8frWYiPBiKWZoL3RVXpNOQc0Rm2p0NKdvJtxUYqgEDRihAiyF 8/WkpBsPNTJdeR3oJlMV9TU/RqwhMSVpUO5GLGzFfGAzSYk/4U0GgdR7jorpY8j6O3YT RT8R7WkpLTVoN3su7Fqe15PXHG/TFxsnPixdKOnq+xnUO0d8FdcvE2DH28g0rSqmwl+c /9CxJL1wCAE/xv730rFhhIClWLq/91fOqG0j74IF/d3ZyXGeG1hi6rpS5EJMo0gUl8ch dw/5dFEoKFvXEJd/vYDe4f9A5X726KSfpTBGAO5dVE3ND00Qh3xMnfc+fWYWjI2CjFE2 6xdQ== X-Gm-Message-State: APjAAAW+AL+e9LHYCVvyZXZktj2TaadqWCSRvLalRGkOnZpTyGn56kSu hiJ1/up+QFgEABFFVz6KoNBCZKUgQLQMtemEJj0mfknMV0A= X-Google-Smtp-Source: APXvYqxm2cJwfrXYN3MHzDPv/Cjc4M/gKYCClvxjNxa94SZjD/MffqdaKAcpk8iD7Aegwatj380tqVj/7JZb+KlCoA8= X-Received: by 2002:ab0:14c6:: with SMTP id f6mr14485165uae.30.1553532008050; Mon, 25 Mar 2019 09:40:08 -0700 (PDT) MIME-Version: 1.0 From: Keith Brian Tomo Date: Tue, 26 Mar 2019 00:39:56 +0800 Message-ID: To: tlp-interest@ietf.org, legal@creativecommons.org, tlp-interest-owner@ietfa.amsl.com, tlp-interest-owner@ietf.org, tlp-interest-request@ietf.org, oauth-request@ietf.org, oauth@ietf.org, apps-help@google.com, talk@globe.com.ph Content-Type: multipart/alternative; boundary="0000000000007cb52e0584eddb51" Archived-At: Subject: [OAUTH-WG] All rights reserved X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 16:40:11 -0000 --0000000000007cb52e0584eddb51 Content-Type: text/plain; charset="UTF-8" All rights reserved. --0000000000007cb52e0584eddb51 Content-Type: text/html; charset="UTF-8"
All rights reserved.
--0000000000007cb52e0584eddb51-- From nobody Mon Mar 25 10:05:16 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54B512051F for ; Mon, 25 Mar 2019 10:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=reminetworks.com 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 CIpZj7RI5_WY for ; Mon, 25 Mar 2019 10:05:06 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 076111204E0 for ; Mon, 25 Mar 2019 10:05:01 -0700 (PDT) Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 3B038175A8A for ; Mon, 25 Mar 2019 10:51:04 -0600 (MDT) Received: from host125.hostmonster.com ([74.220.207.125]) by cmsmtp with ESMTP id 8SoRhRTALXFO58SoRh7Fm1; Mon, 25 Mar 2019 10:51:04 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date: Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IXIdvs5dvMOjBltI8EZzMt9WMcN0xs/4PNIgUxSEFUc=; b=d9zmiDV7cZHKBJ5/XVw4fAyov ZAO8L+m758+Ke2W523oRGwdIGAnIk2IX5N0ZOPp+3eJ1P6Kk3PDARsROG0SqErB3l3K5tyK1huWZP iuE8+IbTC0zoWCsrU2/4Bp2n+M; Received: from 162-206-229-38.lightspeed.tukrga.sbcglobal.net ([162.206.229.38]:54685 helo=DESKTOPLIOIB6R) by host125.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h8SoR-000pnH-Ka; Mon, 25 Mar 2019 10:51:03 -0600 From: To: "'Dominick Baier'" , "'Hans Zandbelt'" Cc: "'IETF oauth WG'" , "'Nov Matake'" , References: In-Reply-To: Date: Mon, 25 Mar 2019 12:51:02 -0400 Message-ID: <025601d4e32a$ef918510$ceb48f30$@reminetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0257_01D4E309.68816BB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIwgA4L/thS5xrVIYxSuUg+/ebS0QJruZ5xAx7kx8ICRKR1QgIl3tkUpRWrU/A= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host125.hostmonster.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - reminetworks.com X-BWhitelist: no X-Source-IP: 162.206.229.38 X-Source-L: No X-Exim-ID: 1h8SoR-000pnH-Ka X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 162-206-229-38.lightspeed.tukrga.sbcglobal.net (DESKTOPLIOIB6R) [162.206.229.38]:54685 X-Source-Auth: donald.coffin@reminetworks.com X-Email-Count: 5 X-Source-Cap: cmVtaW5ldHc7cmVtaW5ldHc7aG9zdDEyNS5ob3N0bW9uc3Rlci5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 17:05:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0257_01D4E309.68816BB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dominick, =20 While you assumption of how OIDC and OAuth are used may apply to = Federated solutions, the North American Energy Standards Board (NAESB) = Energy Service Provider Interface (ESPI) REQ.21, which defines the data = transmission standard for Energy utilities (electricity, gas, and water) = to use in providing consumer=E2=80=99s and Third Party applications = information about their customer=E2=80=99s energy consumption only = allows OAuth 2.0 opaque ATs. The Green Button Alliance, is reviewing how to update the standard to = utilize the various IETF standards associated with OIDC this coming = year, but currently the standard does NOT support a mixture of OIDC and = OAuth. I am very happy to see the IETF attempting to standardize the = content and usage of JWT based OAuth ATs. =20 Best regards, Don Donald F. Coffin Founder/CTO =20 REMI Networks 2335 Dunwoody Xing #E Dunwoody, GA 30338-8221 =20 Phone: (949) 636-8571 Email: donald.coffin@reminetworks.com = =20 =20 From: Dominick Baier =20 Sent: March 25, 2019 10:39 AM To: Hans Zandbelt Cc: IETF oauth WG ; Nov Matake ; = vittorio@auth0.com Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 =20 Yes I know - and I think in hindsight it was a mistake to use the same = claim type for multiple semantics. =20 All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making = things more complicated than they need to be - in my experience almost = no-one (that I know) does OIDC only - nor OAuth only. They always = combine it.. =20 In reality this leads to potential security problems - this spec has the = potential to rectify the situation. =20 Dominick =20 On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu = ) wrote: Without agreeing or disagreeing: OIDC does not apply here since it is = not OAuth and an access token is not an id_token. The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: =20 "The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific" =20 which kind of spells "client" in case of the client credentials grant = but I also do worry about Resource Servers thinking/acting only in terms = of users =20 Hans. =20 On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = > wrote: IMHO the sub claim should always refer to the user - and nothing else. =20 OIDC says: =20 "Subject - Identifier for the End-User at the Issuer." =20 client_id should be used to identify clients. =20 cheers Dominick =20 On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com = ) wrote: Hi Vittorio,=20 =20 Thanks for the good starting point of standardizing JWT-ized AT. =20 One feedback. The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and client, in this spec. It requires those 2 types of identifiers to be unique each other in the = IdP context. =20 I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so = that no such constraint needed. =20 thanks =20 nov On Mar 25, 2019, at 8:29, Vittorio Bertocci = > wrote: =20 Dear all,=20 I just submitted a draft describing a JWT profile for OAuth 2.0 access = tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting = remotely). I look forward for your comments! =20 Here's just a bit of backstory, in case you are interested in how this = doc came to be. The trajectory it followed is somewhat unusual. * Despite OAuth2 not requiring any specific format for ATs, through the = years I have come across multiple proprietary solution using JWT for = their access token. The intent and scenarios addressed by those = solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. * I asked several individuals from key products and services to share = with me concrete examples of their JWT access tokens (THANK YOU Dominick = Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian = (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). I studied and compared all those instances, identifying commonalities = and differences.=20 * I put together a presentation summarizing my findings and suggesting a = rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jw= t_profile_for_ats.pptx = ) - got early feedback from Filip Skokan on = it. Thx Filip! * The presentation was followed up by 1.5 hours of unconference = discussion, which was incredibly valuable to get tight-loop feedback and = incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, = Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and = contributed generously to the discussion. Thank you!!! Note: if you were at OSW2019, participated in the discussion and didn't = get credited in the draft, my apologies: please send me a note and I'll = make things right at the next update. * On my flight back I did my best to incorporate all the ideas and = feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, Hannes and above all Brian were all super helpful in negotiating = the mysterious syntax of the RFC format and submission process. I was blown away by the availability, involvement and willingness to = invest time to get things right that everyone demonstrated in the = process. This is an amazing community.=20 V. _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 -- hans.zandbelt@zmartzone.eu =20 ZmartZone IAM - www.zmartzone.eu =20 ------=_NextPart_000_0257_01D4E309.68816BB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dominick,

 

While you = assumption of how OIDC and OAuth are used may apply to Federated = solutions, the North American Energy Standards Board (NAESB) Energy = Service Provider Interface (ESPI) REQ.21, which defines the data = transmission standard for Energy utilities (electricity, gas, and water) = to use in providing consumer=E2=80=99s and Third Party applications = information about their customer=E2=80=99s energy consumption only = allows OAuth 2.0 opaque ATs.

The Green Button Alliance, is = reviewing how to update the standard to utilize the various IETF = standards associated with OIDC this coming year, but currently the = standard does NOT support a mixture of OIDC and OAuth.=C2=A0 I am very = happy to see the IETF attempting to standardize the content and usage of = JWT based OAuth ATs.

 

Best = regards,

Don

Donald F. = Coffin

Founder/CTO

 

REMI = Networks

2335 Dunwoody Xing = #E

Dunwoody, GA = 30338-8221

 

Phone:      (949) = 636-8571

Email:       donald.coffin@reminetworks= .com

 

From: Dominick Baier = <dbaier@leastprivilege.com>
Sent: March 25, 2019 10:39 = AM
To: Hans Zandbelt = <hans.zandbelt@zmartzone.eu>
Cc: IETF oauth WG = <oauth@ietf.org>; Nov Matake <matake@gmail.com>; = vittorio@auth0.com
Subject: Re: [OAUTH-WG] = draft-bertocci-oauth-access-token-jwt-00

 

Yes I know = - and I think in hindsight it was a mistake to use the same claim type = for multiple semantics.

 =

All the = =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things = more complicated than they need to be - in my experience almost no-one = (that I know) does OIDC only - nor OAuth only. They always combine = it..

 =

In reality = this leads to potential security problems - this spec has the potential = to rectify the situation.

 =

Dominick

 =

On 25. = March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu= ) wrote:

<= div>

Without = agreeing or disagreeing: OIDC does not apply here since it is not OAuth = and an access token is not an = id_token.

=

 =

"The = "sub" (subject) claim identifies the principal that is = the

  =  subject of the JWT.  The claims in a JWT are normally = statements

  =  about the subject.  The subject value MUST either be scoped = to be

  =  locally unique in the context of the issuer or be globally = unique.

  =  The processing of this claim is generally application = specific"

 =

which kind = of spells "client" in case of the client credentials grant but = I also do worry about Resource Servers thinking/acting only in terms of = users

 =

Hans.<= /o:p>

 =

On Mon, = Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com&g= t; wrote:

IMHO the = sub claim should always refer to the user - and nothing = else.

 =

OIDC = says:

 =

"Subject - = Identifier for the End-User at the Issuer."=

 =

client_id = should be used to identify clients.

 =

cheers=

Dominick

 =

On 25.. = March 2019 at 05:13:03, Nov Matake (matake@gmail.com) = wrote:

Hi = Vittorio,

 =

Thanks for = the good starting point of standardizing JWT-ized = AT.

 =

One = feedback.

The = =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-user = and client, in this spec.

It = requires those 2 types of identifiers to be unique each other in the IdP = context.

 =

I prefer = omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so that no = such constraint needed.

 =

thanks=

 =

nov



On Mar 25, = 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:

 =

Dear all, =

I just = submitted a draft describing a JWT profile for OAuth 2.0 access tokens. = You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-a= ccess-token-jwt/.

I have a = slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). = I look forward for your comments!

 =

Here's = just a bit of backstory, in case you are interested in how this doc came = to be. The trajectory it followed is somewhat = unusual.

  • Despite = OAuth2 not requiring any specific format for ATs, through the years I = have come across multiple proprietary solution using JWT for their = access token. The intent and scenarios addressed by those solutions are = mostly the same across vendors, but the syntax and interpretations in = the implementations are different enough to prevent developers from = reusing code and skills when moving from product to = product.
  • I asked = several individuals from key products and services to share with me = concrete examples of their JWT access tokens (THANK YOU Dominick Baier = (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian = (Microsoft), Karl Guinness (Okta) for the tokens and = explanations!).
    I studied and compared all those instances, = identifying commonalities and = differences. 
  • I put = together a presentation summarizing my findings and suggesting a rough = interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slid= es/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from = Filip Skokan on it. Thx Filip!
  • The = presentation was followed up by 1.5 hours of unconference discussion, = which was incredibly valuable to get tight-loop feedback and incorporate = new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten = Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there = and contributed generously to the discussion. Thank you!!!
    Note: if = you were at OSW2019, participated in the discussion and didn't get = credited in the draft, my apologies: please send me a note and I'll make = things right at the next update.
  • On my = flight back I did my best to incorporate all the ideas and feedback in a = draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and = above all Brian were all super helpful in negotiating the mysterious = syntax of the RFC format and submission = process.

I was = blown away by the availability, involvement and willingness to invest = time to get things right that everyone demonstrated in the process. This = is an amazing community. 

V.

___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 =

___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


 =

--

------=_NextPart_000_0257_01D4E309.68816BB0-- From nobody Mon Mar 25 10:32:12 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D83120594 for ; Mon, 25 Mar 2019 10:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 a1Tsu3ClngO1 for ; Mon, 25 Mar 2019 10:32:08 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50075.outbound.protection.outlook.com [40.107.5.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C37120587 for ; Mon, 25 Mar 2019 10:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dmx+3+pG8EFl5OowiSPJeww9FvHncKB0dbot+xhhlLA=; b=ADWSTntL8hIOHNKpRKckqd2kKc7+8XCFwGgPUENAFbNgVhhFDkem4GCPPVdKm84s6zjG2Oo42YGe/yDTtDbjPS0JUojpWjwX+96AV3WtWJtL/24n/5+oMoeDLp/zFKIrAchxZ5uLtt1LvffFbnvp7r+35wcLxlcTxmcB/nZVua4= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1663.eurprd08.prod.outlook.com (10.168.66.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Mon, 25 Mar 2019 17:32:05 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65%11]) with mapi id 15.20.1730.019; Mon, 25 Mar 2019 17:32:05 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: Re-sending "Conclusion ... OAuth Security Topics -- Recommend authorization code instead of implicit" Thread-Index: AdTjIr/Q+MihaIG6Skqe6Xs8HPqVAw== Date: Mon, 25 Mar 2019 17:32:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [2001:67c:1232:144:10d5:263b:5d28:2ee9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf1ef099-1b6d-441b-04f7-08d6b147ccf3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1663; x-ms-traffictypediagnostic: VI1PR0801MB1663: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(39860400002)(396003)(376002)(40434004)(199004)(189003)(102836004)(81166006)(81156014)(6436002)(53936002)(10710500007)(106356001)(105586002)(52536014)(790700001)(6116002)(5660300002)(8676002)(7736002)(478600001)(316002)(486006)(72206003)(86362001)(8936002)(256004)(14444005)(476003)(4744005)(2420400007)(55016002)(25786009)(7696005)(186003)(54896002)(236005)(7110500001)(99286004)(15650500001)(14454004)(33656002)(68736007)(966005)(74316002)(5024004)(46003)(71200400001)(71190400001)(2906002)(97736004)(6506007)(606006)(9686003)(6306002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1663; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hTGyWlAQVvRMLrY2C7fI1/Ml+kT78HaivI4X9yLxEEJ+1Ae704/1IE7lR1J2N2ps5mCyVw2raSOm8o6tZHTDfc8hE4xpkWWgsrYnbhInr68yY9OfZZbfFayIY957IzYBu5b5TF//Ve44NYsmIMW7t5VQ87nSkGQKRzHoo3/maHz8nXLqrUNpBeAsu3IGXJjbrgax4fSph3mhlL4Xn8jB9ptLm/QKUmWpBlYcrZtXth7QShM1kVDxoObIUMjzyLDQkWpqeIDveMsQSIgXIdv9gvDmIIeI2LBO6UsTjrr7S8GK1aetYboEJ/GNpAmYmlxIt6nwtUxEps5Dt+3wDmnV95WhI1UwIaoFIXvS5dA0JcPFImKKd0dgUPAo7e4DGT4kvfzs1jskXadNwhI2cDeewxoZ5o501XkZFZvYQuEJfOI= Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211286C7BE09ED3D7C279FF0FA5E0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf1ef099-1b6d-441b-04f7-08d6b147ccf3 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 17:32:05.6765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1663 Archived-At: Subject: [OAUTH-WG] Re-sending "Conclusion ... OAuth Security Topics -- Recommend authorization code instead of implicit" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 17:32:11 -0000 --_000_VI1PR0801MB211286C7BE09ED3D7C279FF0FA5E0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am re-sending the conclusion summary email following the discussion about= the implicit grant, as discussed in the OAuth WG meeting in Prague today. https://mailarchive.ietf.org/arch/msg/oauth/mLWi6wji31qOkciSgPjXPK98ydc Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB211286C7BE09ED3D7C279FF0FA5E0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am re-sending the conclusion summary email followi= ng the discussion about the implicit grant, as discussed in the OAuth WG me= eting in Prague today.

https://mailarchive.ietf.org/arch/msg/oauth= /mLWi6wji31qOkciSgPjXPK98ydc

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB211286C7BE09ED3D7C279FF0FA5E0VI1PR0801MB2112_-- From nobody Mon Mar 25 16:51:50 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5940B12016B for ; Mon, 25 Mar 2019 16:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 IBIrix5KqK2R for ; Mon, 25 Mar 2019 16:51:43 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB4E120158 for ; Mon, 25 Mar 2019 16:51:43 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id r25so7289316lfn.13 for ; Mon, 25 Mar 2019 16:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VXOaTjpoqL71kmjf+MJ69j2JPjLm0bAqeV5zLQCMqqM=; b=kG0MsQ+CjbRqVve4PZl8aFARum9DyShmYcMPl6juTTiiH4WenNa0C8sOPn2IMHAILw aQbmRisotmmdYXmTCX9ZhtRTA9LsS198S6+P/XScPh3R946ssiWjac+sMRjZtABjgXfC zJwx4XH4mqDZVtOvcuMDNJzRAYhUOaNZm3OCSoycV3gADPV8k3n+tjtY4ufDfvPy4L+V BqnGYbxwzy1IY3FEKcl5kf+iPVbekJY6+gcYEYkYR2Fcp0OrwosJsi5lr4kWTLS0SDS4 nJEruAUky0gKO3jYx2v4m4ukOtyuB4JVg523DeaooQ096LZ9PuIZx0v6nbNqZ8HRnZz/ S70g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VXOaTjpoqL71kmjf+MJ69j2JPjLm0bAqeV5zLQCMqqM=; b=KoGp4afcyx68L+3v85jM6rNZWf2bAlG8lEHYGFxdCKVqCdNHEqOjqZS+cDKaEGeu8V NHBPsOueWpGdL2T0Ox++GorhJUBkjSU9UMdDBjPdMZhsTAxvT6qahLLVJJHPsHNpM0pl is43zsDyLCUNsenSNrP1HKLDSVa2g0/wS0HlrXMjaElpGa3SabuoQGk03AxPPxxDvlrD dVxuilPCxtueL1LhoaCDCTl4R4ZXcwvaw2dyhEu0CZc3/bnlmNB4eF1YI5w6+tYO0BBB GyzYVkwmzJuiZtO4RR18olgQhzE4WGMEefAzNVJ6wnDXlvAONTMhqCtcubSl+cy8T0Hn ++cA== X-Gm-Message-State: APjAAAXhXl0mLSf8GVvGqI/LEw19sv5cZYjYzKUbYACTkWH47/I5qYye WHc7xfvv21fPYmKChS75BVxgTnRgDtWzfCWk3JsRvg== X-Google-Smtp-Source: APXvYqxnY592obemZqN24qp8tjXh7R6joMTL9CJtDWG1vCjvZXhQEEarEVTnip++uamC+9iZaMiN5mPlrWLgvg1ntwQ= X-Received: by 2002:a19:c005:: with SMTP id q5mr13684836lff.96.1553557901094; Mon, 25 Mar 2019 16:51:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vittorio Bertocci Date: Mon, 25 Mar 2019 16:51:31 -0700 Message-ID: To: Hans Zandbelt Cc: Dominick Baier , IETF oauth WG , Nov Matake Content-Type: multipart/alternative; boundary="000000000000d549ac0584f3e26e" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 23:51:49 -0000 --000000000000d549ac0584f3e26e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Nov, Dominick, Hans- thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify. The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent. The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_i= d, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server. Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk? Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production? Thanks V. On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt wrote: > I believe there are plenty of OAuth 2.0 only use cases out there... but > nevertheless I agree with the potential confusion and thus security > problems arising from that (though one may argue the semantics are the > same). > > Hans. > > On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier > wrote: > >> Yes I know - and I think in hindsight it was a mistake to use the same >> claim type for multiple semantics. >> >> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making th= ings more >> complicated than they need to be - in my experience almost no-one (that = I >> know) does OIDC only - nor OAuth only. They always combine it. >> >> In reality this leads to potential security problems - this spec has the >> potential to rectify the situation. >> >> Dominick >> >> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu= ) >> wrote: >> >> Without agreeing or disagreeing: OIDC does not apply here since it is no= t >> OAuth and an access token is not an id_token. >> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: >> >> "The "sub" (subject) claim identifies the principal that is the >> subject of the JWT. The claims in a JWT are normally statements >> about the subject. The subject value MUST either be scoped to be >> locally unique in the context of the issuer or be globally unique. >> The processing of this claim is generally application specific" >> >> which kind of spells "client" in case of the client credentials grant bu= t >> I also do worry about Resource Servers thinking/acting only in terms of >> users >> >> Hans. >> >> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier >> wrote: >> >>> IMHO the sub claim should always refer to the user - and nothing else. >>> >>> OIDC says: >>> >>> "Subject - Identifier for the End-User at the Issuer." >>> >>> client_id should be used to identify clients. >>> >>> cheers >>> Dominick >>> >>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>> >>> Hi Vittorio, >>> >>> Thanks for the good starting point of standardizing JWT-ized AT. >>> >>> One feedback. >>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-= user and client, >>> in this spec. >>> It requires those 2 types of identifiers to be unique each other in the >>> IdP context. >>> >>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so t= hat no such >>> constraint needed. >>> >>> thanks >>> >>> nov >>> >>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>> >>> Dear all, >>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>> tokens. You can find it in >>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/= . >>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>> remotely). I look forward for your comments! >>> >>> Here's just a bit of backstory, in case you are interested in how this >>> doc came to be. The trajectory it followed is somewhat unusual. >>> >>> - Despite OAuth2 not requiring any specific format for ATs, through >>> the years I have come across multiple proprietary solution using JWT= for >>> their access token. The intent and scenarios addressed by those solu= tions >>> are mostly the same across vendors, but the syntax and interpretatio= ns in >>> the implementations are different enough to prevent developers from = reusing >>> code and skills when moving from product to product. >>> - I asked several individuals from key products and services to >>> share with me concrete examples of their JWT access tokens (THANK YO= U >>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and >>> explanations!). >>> I studied and compared all those instances, identifying >>> commonalities and differences. >>> - I put together a presentation summarizing my findings and >>> suggesting a rough interoperable profile (slides: >>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-= _a_jwt_profile_for_ats.pptx >>> >>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>> - The presentation was followed up by 1.5 hours of unconference >>> discussion, which was incredibly valuable to get tight-loop feedback= and >>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvin= ov, >>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>> and contributed generously to the discussion. Thank you!!! >>> Note: if you were at OSW2019, participated in the discussion and >>> didn't get credited in the draft, my apologies: please send me a not= e and >>> I'll make things right at the next update. >>> - On my flight back I did my best to incorporate all the ideas and >>> feedback in a draft, which will be discussed at IETF104 tomorrow. Ri= faat, >>> Hannes and above all Brian were all super helpful in negotiating the >>> mysterious syntax of the RFC format and submission process. >>> >>> I was blown away by the availability, involvement and willingness to >>> invest time to get things right that everyone demonstrated in the proce= ss. >>> This is an amazing community. >>> V. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> >> > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > --000000000000d549ac0584f3e26e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Nov, Dominick, Hans-
thanks for the comments. That= was an area I was expecting to cause more discussion, and I am glad we are= having this opportunity to clarify.
The current language in the = draft traces the etymology of sub to OpenID Connect core, hence Dominick ob= servation is on point. However in the description I express something in li= ne with 7519, which was in fact my intent.

The ide= a was to provide an identifier of the calling subject that is guaranteed to= be present in all cases- this would allow an SDK developer to use the same= code for things like lookups and membership checks regardless of the natur= e of the caller (user in a delegated case, app in app-only grants). The inf= ormation to discriminate between user and app callers is always available i= n the token (say, the caller is a user if sub!=3Dclient_id, where client_id= is always guaranteed to be present as well) hence there's no loss in e= xpressive power, should that difference be relevant for the resource server= .

Dominick, Hans- I probably missed the security i= ssue you guys are thinking of in this case. Of course, if this would introd= uce a risk I completely agree it should be changed- I'd just like to un= derstand better the problem. Could you expand it in a scenario/use case to = clarify the risk?
Nov- playing this back: is the concern that a u= ser and a client might have the same identifier within an IDP? When using c= ollision resistant IDs, as it is usually the case, that seems to be a remot= e possibility- did you stumble in such scenario in production?
Thanks
V.=C2=A0


On Mon, Mar 25, = 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
I believ= e there are plenty of OAuth 2.0 only use cases out there... but nevertheles= s I agree with the potential confusion and thus security problems arising f= rom that (though one may argue the semantics are the same).

Hans.

On Mon, Mar 25, 2019 at 3:39 PM Dominick Baie= r <dbaier= @leastprivilege.com> wrote:
Yes I know - and I think in hindsight it was a mistake to use the sa= me claim type for multiple semantics.

All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D argumen= ts are making things more complicated than they need to be - in my experien= ce almost no-one (that I know) does OIDC only - nor OAuth only. They always= combine it.

In rea= lity this leads to potential security problems - this spec has the potentia= l to rectify the situation.

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.

"The "sub" (subject) claim identifies the principal tha= t is the
=C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are normally statements
=C2=A0 =C2=A0about the subject.=C2=A0 The subject value MUST either be scoped to be
=C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
=C2=A0 =C2=A0The processing of this claim is generally application specific"

which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

Hans.

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
IMHO the sub claim should always refer to the user - and nothing else.

OIDC says:

"Subject - Identifier for the End-User at the Issuer."

client_id should be used to identify clients.

cheers
Dominick

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.
The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
It requires those 2 types of identifiers to be unique each other in the IdP context.

I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

thanks

nov
On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--


--
--000000000000d549ac0584f3e26e-- From nobody Mon Mar 25 17:11:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AB2120158 for ; Mon, 25 Mar 2019 17:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 lPmBDF_Eu5gB for ; Mon, 25 Mar 2019 17:11:44 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6831A12011F for ; Mon, 25 Mar 2019 17:11:43 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id 10so7322464lfr.8 for ; Mon, 25 Mar 2019 17:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ckU9PaLToLPGXGiwcNRV9RhhN7NhoQwV8kUjLzx2ZpE=; b=eOvLNBXONzVdgbZnrw27wy/3/52LvnG6bz+sbbAFzYOcA58bPWRVcGlFlcNRUfhmz9 Ir9QfpxsQGH0LiOACCv5mv2s3fP5D+jITj3qLsd7wol9hHdVeQqMRe8NF6swTJIbkJUW eaqj2ji8pPvTnKea1j97vch/JJlR5z+aEuOT3wx/+NlVmCAdU3JILWa4bn7hJLqQgx4J X7Can4/xCtP+W+ZN988YqW5/7AKVAbpWqkfQKEk6SQbUdhhczOw8koIJxv/3o5DDt6Vf C90RwbLsu70gm8AcWEnlnSieZ9DB0Uy4zujt72ANCa86KfDx2LM8noDR6XLLQYkYeCgJ aNaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ckU9PaLToLPGXGiwcNRV9RhhN7NhoQwV8kUjLzx2ZpE=; b=f8Q5Qhx02Wc+ynBkbrrNazV7tHjyDqQAJEv6hEg48poNdFwMekZNWeaHBG8Py0Rs6N /mmumdCjtKSHgK6MaE6c33dyI6viXF9CkQAKLpEnErQRFTW3KlioRpQ0wYlYIgAluwDt BcYJhXv6I5D23hwYQPtl5Yq1cyBSUG9bSqen1KJKP4NNk8bcenKl1Yaq3clf49QVtLLq fDkkGwH2z2400TH/g6enCfE8tHxIS8pVN6ijtmUL2l+gbPAcyUlKukSdyCff4PVfZXpG nVav4M4G+GqDCyC60To4pnfqL8T4oHrhLffYsWzqsLW3OfYbx3ZzoqhYyAENHPdwyai0 YbNA== X-Gm-Message-State: APjAAAXYFe5cKr6+dAjCk2isf+abFzpl7Ph0LFpCZXc9xWo7mtLevuNh rqVt9OD+2uG5KCk56zex/AlIqLbQEaZopxIg6HFCpTt3/ag+Lg== X-Google-Smtp-Source: APXvYqzjdmS2IPB4EXuq/q0Zw1BonQohrI0wZT/qkuGu6VCrWgF9/YrzR9QDkK2vJEeulWr5zriBYmaYwkgF73X0MVs= X-Received: by 2002:a19:9e0d:: with SMTP id h13mr13405829lfe.51.1553559101205; Mon, 25 Mar 2019 17:11:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vittorio Bertocci Date: Mon, 25 Mar 2019 17:11:31 -0700 Message-ID: To: CARLIER Bertrand Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000005d86cd0584f42af0" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 00:11:47 -0000 --0000000000005d86cd0584f42af0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Bertrand for your comments and kind words! Inline > In addition to the "sub" claim (I agree it should only relate to the end > user, not the client_id), See the reply to Dominick & Hans on this. Do you have specific case/attack in mind? I think the scope claim should be mentioned as OPTIONAL in =C2=A72.2 (it's > already mentioned in other parts of the draft) Mmh, let me clarify... the fact that the scope soemtrimes doesn;t show up doesn;t automatically mean it's optional. Per the current formulation, I am suggesting that when *scope *is present in the request, a *scope* claim is *required (*hence not optional*) *in the resulting token. When scope isn't present in the incoming request, I didn't go all the way to explicitly disallow it but it doesn't seem to be necessary in the resulting token. What do you think? - Should we mention security recommendation on the JWT (like DO NOT USE > alg=3D"none") and maybe refer to > *https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html* > ? That is an excellent idea. Thank you! - Should we mention the "act" claim defined by Token Exchange as a possible > claim for JWT access tokens? My bias would be to keep the set of things we mention in the profile to the essential of what has been observed in concrete use, to keep the cognitive burden of consuming the spec to the bare minimum. Currently there's no language reminding the reader that they can add any extra claims they like, but that should be true by default for all those specs. How strongly do you feel about the value of explicitly mentioning "act" already in v1 of the profile? - any reason to rely on RFC 7662 (Introspection) for the token format? I > see that the "nbf" (not before) claim is defined there Do you mean "not rely" by any chance? The current set of claims in the layout derives from observing what's most commonly used, combined with the fact that many JWT validators used in the wild are geared to work with id_tokens (hence more likely to work as is with the new profile, always remembering the at+typ measure). In particular, nbf was brought up during OSW2019 and, given its relatively rare occurrence (only AAD and IS had it), I was advised to improve the signal/noise ratio and cut it. On Mon, Mar 25, 2019 at 7:55 AM CARLIER Bertrand < Bertrand.CARLIER@wavestone.com> wrote: > Hi Vittorio, > > Very nice work ! > > Here are a few ideas: > - In addition to the "sub" claim (I agree it should only relate to the en= d > user, not the client_id), I think the scope claim should be mentioned as > OPTIONAL in =C2=A72.2 (it's already mentioned in other parts of the draft= ) > - Should we mention security recommendation on the JWT (like DO NOT USE > alg=3D"none") and maybe refer to > *https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html* > ? > - Should we mention the "act" claim defined by Token Exchange as a > possible claim for JWT access tokens? > - any reason to rely on RFC 7662 (Introspection) for the token format? I > see that the "nbf" (not before) claim is defined there > > Regards, > -- > > *Bertrand CARLIER * > > *From:* OAuth *On Behalf Of *Vittorio Bertocci > *Sent:* lundi 25 mars 2019 00:29 > *To:* IETF oauth WG > *Subject:* [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > > Dear all, > I just submitted a draft describing a JWT profile for OAuth 2.0 access > tokens. You can find it in > *https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/* > = . > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting > remotely). I look forward for your comments! > > Here's just a bit of backstory, in case you are interested in how this do= c > came to be. The trajectory it followed is somewhat unusual. > > - Despite OAuth2 not requiring any specific format for ATs, through > the years I have come across multiple proprietary solution using JWT f= or > their access token. The intent and scenarios addressed by those soluti= ons > are mostly the same across vendors, but the syntax and interpretations= in > the implementations are different enough to prevent developers from re= using > code and skills when moving from product to product. > - I asked several individuals from key products and services to share > with me concrete examples of their JWT access tokens (THANK YOU Domini= ck > Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian > (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). > I studied and compared all those instances, identifying commonalities > and differences. > - I put together a presentation summarizing my findings and suggesting > a rough interoperable profile (slides: > *https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_= a_jwt_profile_for_ats.pptx* > > ) - got early feedback from Filip Skokan on it. Thx Filip! > - The presentation was followed up by 1.5 hours of unconference > discussion, which was incredibly valuable to get tight-loop feedback a= nd > incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov= , > Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there > and contributed generously to the discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a note = and > I'll make things right at the next update. > - On my flight back I did my best to incorporate all the ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. Rifa= at, > Hannes and above all Brian were all super helpful in negotiating the > mysterious syntax of the RFC format and submission process. > > I was blown away by the availability, involvement and willingness to > invest time to get things right that everyone demonstrated in the process= . > This is an amazing community. > V. > > The information transmitted in the present email including the attachment > is intended only for the person to whom or entity to which it is addresse= d > and may contain confidential and/or privileged material. Any review, > retransmission, dissemination or other use of, or taking of any action in > reliance upon this information by persons or entities other than the > intended recipient is prohibited. If you received this in error, please > contact the sender and delete all copies of the material. > > Ce message et toutes les pi=C3=A8ces qui y sont =C3=A9ventuellement joint= es sont > confidentiels et transmis =C3=A0 l'intention exclusive de son destinatair= e. > Toute modification, =C3=A9dition, utilisation ou diffusion par toute pers= onne ou > entit=C3=A9 autre que le destinataire est interdite. Si vous avez re=C3= =A7u ce > message par erreur, nous vous remercions de nous en informer imm=C3=A9dia= tement > et de le supprimer ainsi que les pi=C3=A8ces qui y sont =C3=A9ventuelleme= nt jointes. > --0000000000005d86cd0584f42af0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Bertrand for your comments and kind words!
I= nline
=C2=A0In addition to the "su= b" claim (I agree it should only relate to the end user, not the clien= t_id),=C2=A0
See the reply to Dominick & Hans on this. Do you have= specific case/attack in mind?

I think the scope claim should be mentioned as OPTIONAL in =C2=A72.2 (it&= #39;s already mentioned in other parts of the draft)=C2=A0=C2=A0
Mmh, let me clarify... the fact that the scope soemtrimes doe= sn;t show up doesn;t automatically mean it's optional. Per the current = formulation, I am suggesting that when scope is present in the reque= st, a scope claim is required (hence not optional)=C2=A0in the resulting token. When scope isn't present in the incoming requ= est, I didn't go all the way to explicitly disallow it but it doesn'= ;t seem to be necessary in the resulting token. What do you think?

- Should= we mention security recommendation on the JWT (like DO NOT USE alg=3D"= ;none") and maybe refer to=C2=A0= https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html= =C2=A0?
= That is an excellent idea. Thank you!

- Should we mention the "act" claim defined by Token Exch= ange as a possible claim for JWT access tokens?
My bias would be to keep the set of= things we mention in the profile to the essential of what has been observe= d in concrete use, to keep the cognitive burden of consuming the spec to th= e bare minimum. Currently there's no language reminding the reader that= they can add any extra claims they like, but that should be true by defaul= t for all those specs. How strongly do you feel about the value of explicit= ly mentioning "act" already in v1 of the profile?

- any reason to rely on RFC 7662 (Introspecti= on) for the token format? I see that the "nbf" (not before) claim= is defined there
Do you mean "not rely" by any chance?=C2=A0
Th= e current set of claims in the layout derives from observing what's mos= t commonly used, combined with the fact that many JWT validators used in th= e wild are geared to work with id_tokens (hence more likely to work as is w= ith the new profile, always remembering the at+typ measure).
In particul= ar, nbf was brought up during OSW2019 and, given its relatively rare occurr= ence (only AAD and IS had it), I was advised to improve the signal/noise ra= tio and cut it.


On Mon, Mar 25, 2019 at 7:55 AM CARLIER Bertrand <Bertrand.CARLIER@wavestone.com&g= t; wrote:
Hi Vittorio,
=C2=A0
Very nice work=C2=A0!
=C2=A0
Here are a few ideas:
- In addition to the "sub" claim (I agree it should only rel= ate to the end user, not the client_id), I think the scope claim should be = mentioned as OPTIONAL in =C2=A72.2 (it's already mentioned in other par= ts of the draft)
- Should we mention security recommendation on the JWT (like DO NOT US= E alg=3D"none") and maybe refer to https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html ?
- Should we mention the "act" claim defined by Token Exchang= e as a possible claim for JWT access tokens?
- any reason to rely on RFC 7662 (Introspection) for the token format?= I see that the "nbf" (not before) claim is defined there
=C2=A0
Regards,
--
Bertrand CARLIER
=C2=A0
From: OAuth <oauth-bounces@ietf.org> On Behalf Of Vittorio Be= rtocci
Sent: lundi 25 mars 2019 00:29
To: IETF oauth WG <oauth@ietf.org>
Subject: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
=C2=A0
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access= tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token= -jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presen= ting remotely). I look forward for your comments!
=C2=A0
Here's just a bit of backstory, in case you are interested in how = this doc came to be. The trajectory it followed is somewhat unusual.
  • Despite OAuth2 not requiring= any specific format for ATs, through the years I have come across multiple= proprietary solution using JWT for their access token. The intent and scen= arios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in t= he implementations are different enough to prevent developers from reusing = code and skills when moving from product to product.
  • I asked several individuals from key products = and services to share with me concrete examples of their JWT access tokens = (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) = for the tokens and explanations!).
    I studied and compared all those instances, identifying commonalities and d= ifferences.=C2=A0
  • I put = together a presentation summarizing my findings and suggesting a rough inte= roperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2= 019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
  • The presentation was followed up by 1.5 = hours of unconference discussion, which was incredibly valuable to get tigh= t-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vla= dimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sakim= ura, Hannes Tschofenig=C2=A0were all there and contributed ge= nerously to the discussion. Thank you!!!
    Note: if you were at OSW2019, participated in the discussion and didn't= get credited in the draft, my apologies: please send me a note and I'l= l make things right at the next update.
  • On my flight back I did my best to incorporate all the idea= s and feedback in a draft, which will be discussed at IETF104 tomorrow. Rif= aat, Hannes and above all Brian were all super helpful in negotiating the m= ysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to i= nvest time to get things right that everyone demonstrated in the process. T= his is an amazing community.=C2=A0
V.
=C2=A0
The information transmitted in the present email including the atta= chment is intended only for the person to whom or entity to which it is add= ressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use= of, or taking of any action in reliance upon this information by persons o= r entities other than the intended recipient is prohibited. If you received= this in error, please contact the sender and delete all copies of the material.

Ce message et toutes les pi=C3=A8ces qui y sont =C3=A9ventuellement jointes= sont confidentiels et transmis =C3=A0 l'intention exclusive de son des= tinataire. Toute modification, =C3=A9dition, utilisation ou diffusion par t= oute personne ou entit=C3=A9 autre que le destinataire est interdite. Si vous avez re=C3=A7u ce message par erreur, nous vous remercions de nous = en informer imm=C3=A9diatement et de le supprimer ainsi que les pi=C3=A8ces= qui y sont =C3=A9ventuellement jointes.
--0000000000005d86cd0584f42af0-- From nobody Mon Mar 25 17:13:21 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DFA120165 for ; Mon, 25 Mar 2019 17:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 0plZM-5yg-Kk for ; Mon, 25 Mar 2019 17:13:15 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B76112011F for ; Mon, 25 Mar 2019 17:13:14 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id k8so9481900lja.8 for ; Mon, 25 Mar 2019 17:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n7MhYsykUnCCdrrx/q25Mz2LeGgWVPXSr8ztMZa6LGY=; b=bf7rMZf+I2DvZQIwtUEldFRuu+oB0a7tnddRD0bZiYLgKSC6/BmWnURsMrznfArXvo jPNIe+/j7YkznGVca2xjHyDGuoadMY3V1QeyRf5E4n+IQqzGizfGOdm/6A4B7Dk/Y7yq jw0KQ+pY8oidlSU3iVpIewk40GOCCKLJZlkkq0kbkf+pKbPilyl6p6vgDXT6HP4g+fG4 F7DgcNjNvTsKlyv3205V6eDkUiCzKrzgpdZJY2CySBuYT+Q2qMTUM6Lz268yUqq4XHSm 71WjRQLZYiXhEWtghXxE3+02YO/61LWyk4R055g30J8/SzTFIifXLWVFdZ3unFMhcFH3 Hqsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n7MhYsykUnCCdrrx/q25Mz2LeGgWVPXSr8ztMZa6LGY=; b=tXwbZaRPOoI19whWB4V8FiOAZsYR1S8z544lGTF+YR+yBYF1Ru3tZmM0/qHyW9ahV4 bzZfuNpFXjLdh2HWW64j27Bfg4aJbZlQn/mjPzQlyXUWRC3w9OrLx/rn3RSgDqe0xn6A 9mJKAKAFUb+BR1MsDqK9utWbkyLuxlOYyB3uYfQy2D1TywNyJzeYh00l8elsLiht4HJM 4GpulBuAK/3RW6Un67f4QJPNAX405OJRZoIxtBCYlgrb19uUhMeHH4emq2lSWGpNz8L8 RfV9Yp5sEp6BebdAeq4qOOLV3pE4Z/P/B6XVJOpvhCEUmADpCOHtYNSEir9WypnpFpp9 oNUA== X-Gm-Message-State: APjAAAXDnDnIZRkcU8dLgcrKgY18mKj6VsqvCs/+T8WPbY6ySZCNWhlf uGUIzNdnPDIiDgM9nX3ZfOeM/3P1lOb1olvtXYPG2g== X-Google-Smtp-Source: APXvYqz9X8rgrq1SEj4nJ1m1ap6cH0ryDW8z3CogJ8dSm1puQoXGlSZfXaSlXwrTrtgVmRbZNtTaYTHcHSMX/S3qyMU= X-Received: by 2002:a2e:8794:: with SMTP id n20mr10568333lji.76.1553559192134; Mon, 25 Mar 2019 17:13:12 -0700 (PDT) MIME-Version: 1.0 References: <025601d4e32a$ef918510$ceb48f30$@reminetworks.com> In-Reply-To: <025601d4e32a$ef918510$ceb48f30$@reminetworks.com> From: Vittorio Bertocci Date: Mon, 25 Mar 2019 17:13:02 -0700 Message-ID: To: donald.coffin@reminetworks.com Cc: Dominick Baier , Hans Zandbelt , IETF oauth WG , Nov Matake Content-Type: multipart/alternative; boundary="000000000000c920a30584f42fb5" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 00:13:20 -0000 --000000000000c920a30584f42fb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Don for your perspective on this! On Mon, Mar 25, 2019 at 10:13 AM wrote: > Dominick, > > > > While you assumption of how OIDC and OAuth are used may apply to Federate= d > solutions, the North American Energy Standards Board (NAESB) Energy Servi= ce > Provider Interface (ESPI) REQ.21, which defines the data transmission > standard for Energy utilities (electricity, gas, and water) to use in > providing consumer=E2=80=99s and Third Party applications information abo= ut their > customer=E2=80=99s energy consumption only allows OAuth 2.0 opaque ATs. > > The Green Button Alliance, is reviewing how to update the standard to > utilize the various IETF standards associated with OIDC this coming year, > but currently the standard does NOT support a mixture of OIDC and OAuth. = I > am very happy to see the IETF attempting to standardize the content and > usage of JWT based OAuth ATs. > > > > Best regards, > > Don > > Donald F. Coffin > > Founder/CTO > > > > REMI Networks > > 2335 Dunwoody Xing #E > > Dunwoody, GA 30338-8221 > > > > Phone: (949) 636-8571 > > Email: donald.coffin@reminetworks.com > > > > *From:* Dominick Baier > *Sent:* March 25, 2019 10:39 AM > *To:* Hans Zandbelt > *Cc:* IETF oauth WG ; Nov Matake ; > vittorio@auth0.com > *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > > > > Yes I know - and I think in hindsight it was a mistake to use the same > claim type for multiple semantics. > > > > All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making thi= ngs more > complicated than they need to be - in my experience almost no-one (that I > know) does OIDC only - nor OAuth only. They always combine it.. > > > > In reality this leads to potential security problems - this spec has the > potential to rectify the situation. > > > > Dominick > > > > On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) > wrote: > > Without agreeing or disagreeing: OIDC does not apply here since it is not > OAuth and an access token is not an id_token. > > The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: > > > > "The "sub" (subject) claim identifies the principal that is the > > subject of the JWT. The claims in a JWT are normally statements > > about the subject. The subject value MUST either be scoped to be > > locally unique in the context of the issuer or be globally unique. > > The processing of this claim is generally application specific" > > > > which kind of spells "client" in case of the client credentials grant but > I also do worry about Resource Servers thinking/acting only in terms of > users > > > > Hans. > > > > On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier > wrote: > > IMHO the sub claim should always refer to the user - and nothing else. > > > > OIDC says: > > > > "Subject - Identifier for the End-User at the Issuer." > > > > client_id should be used to identify clients. > > > > cheers > > Dominick > > > > On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: > > Hi Vittorio, > > > > Thanks for the good starting point of standardizing JWT-ized AT. > > > > One feedback. > > The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-us= er and client, in > this spec. > > It requires those 2 types of identifiers to be unique each other in the > IdP context. > > > > I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so tha= t no such > constraint needed. > > > > thanks > > > > nov > > > > On Mar 25, 2019, at 8:29, Vittorio Bertocci < > vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: > > > > Dear all, > > I just submitted a draft describing a JWT profile for OAuth 2.0 access > tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > > I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting > remotely). I look forward for your comments! > > > > Here's just a bit of backstory, in case you are interested in how this do= c > came to be. The trajectory it followed is somewhat unusual. > > - Despite OAuth2 not requiring any specific format for ATs, through > the years I have come across multiple proprietary solution using JWT f= or > their access token. The intent and scenarios addressed by those soluti= ons > are mostly the same across vendors, but the syntax and interpretations= in > the implementations are different enough to prevent developers from re= using > code and skills when moving from product to product. > - I asked several individuals from key products and services to share > with me concrete examples of their JWT access tokens (THANK YOU Domini= ck > Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian > (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). > I studied and compared all those instances, identifying commonalities > and differences. > - I put together a presentation summarizing my findings and suggesting > a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a= _jwt_profile_for_ats.pptx > > ) - got early feedback from Filip Skokan on it. Thx Filip! > - The presentation was followed up by 1.5 hours of unconference > discussion, which was incredibly valuable to get tight-loop feedback a= nd > incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov= , > Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there an= d > contributed generously to the discussion. Thank you!!! > Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a note = and > I'll make things right at the next update. > - On my flight back I did my best to incorporate all the ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. Rifa= at, > Hannes and above all Brian were all super helpful in negotiating the > mysterious syntax of the RFC format and submission process. > > I was blown away by the availability, involvement and willingness to > invest time to get things right that everyone demonstrated in the process= . > This is an amazing community. > > V. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > hans.zandbelt@zmartzone.eu > > ZmartZone IAM - www.zmartzone.eu > > --000000000000c920a30584f42fb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Don for your perspective on this!=C2=A0

On Mon, Mar = 25, 2019 at 10:13 AM <= donald.coffin@reminetworks.com> wrote:

Dominick,=

=C2=A0

W= hile you assumption of how OIDC and OAuth are used may apply to Federated s= olutions, the North American Energy Standards Board (NAESB) Energy Service = Provider Interface (ESPI) REQ.21, which defines the data transmission stand= ard for Energy utilities (electricity, gas, and water) to use in providing = consumer=E2=80=99s and Third Party applications information about their cus= tomer=E2=80=99s energy consumption only allows OAuth 2.0 opaque ATs.
The Green Button Alliance, is reviewing how to update the standard to util= ize the various IETF standards associated with OIDC this coming year, but c= urrently the standard does NOT support a mixture of OIDC and OAuth.=C2=A0 I= am very happy to see the IETF attempting to standardize the content and us= age of JWT based OAuth ATs.

= =C2=A0

Best regards,

Don

Donald F. Coffin

<= p class=3D"MsoNormal">Founder/CTO

<= u>=C2=A0

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

=C2=A0

Phone:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 (949) 636-8571

Email:=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com=

=C2=A0

From: = Dominick Baier <dbaier@leastprivilege.com>
Sent: March 25, 2019 10= :39 AM
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: IETF oauth WG <oau= th@ietf.org>; Nov Matake <matake@gmail.com>; vittorio@auth0.com
Subject: Re: [OAUTH-= WG] draft-bertocci-oauth-access-token-jwt-00

<= p class=3D"MsoNormal">=C2=A0

<= span style=3D"font-size:10pt;font-family:Helvetica,sans-serif">Yes I know -= and I think in hindsight it was a mistake to use the same claim type for m= ultiple semantics.

= =C2=A0

All the =E2=80=9Cthis is OID= C not OAuth=E2=80=9D arguments are making things more complicated than they= need to be - in my experience almost no-one (that I know) does OIDC only -= nor OAuth only. They always combine it..

=C2=A0

In real= ity this leads to potential security problems - this spec has the potential= to rectify the situation.

<= u>=C2=A0

Dominick

=C2=A0

On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

=C2=A0

IMHO the sub = claim should always refer to the user - and nothing else.

=C2=A0

OIDC says:

= =C2=A0

"Subject - Identifier for the= End-User at the Issuer."

<= u>=C2=A0

client_id should be us= ed to identify clients.

<= /u>=C2=A0

cheers

Dominick

=C2=A0

On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote= :

Hi Vittorio,

=C2=A0

Thanks for th= e good starting point of standardizing JWT-ized AT.

=C2=A0

One feedback.

The =E2=80= =9Csub=E2=80=9D claim can include 2 types of identifier, end-user and clien= t, in this spec.

= It requires= those 2 types of identifiers to be unique each other in the IdP context.

=C2=A0

I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2= -legged context, so that no such constraint needed.

=C2=A0

thanks

=C2=A0<= /u>

nov



On Mar 25, 2019, at 8:29, V= ittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.or= g> wrote:

=C2=A0=

Dear all,

I just submitted a draft describing a JWT profile f= or OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/= .

I have a slot to discu= ss this tomorrow at IETF 104 (I'll be presenting remotely). I look forw= ard for your comments!

=C2=A0

Here's just a bit of b= ackstory, in case you are interested in how this doc came to be. The trajec= tory it followed is somewhat unusual.

  • Despite OAuth2 not requiring any specific form= at for ATs, through the years I have come across multiple proprietary solut= ion using JWT for their access token. The intent and scenarios addressed by= those solutions are mostly the same across vendors, but the syntax and int= erpretations in the implementations are different enough to prevent develop= ers from reusing code and skills when moving from product to product.
  • I asked several individuals from key produ= cts and services to share with me concrete examples of their JWT access tok= ens (THANK YOU Dominick Baier (IdentityServer),=C2=A0Brian Campbell (PingId= entity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens a= nd explanations!).
    I studied and compared all those instances, identifyi= ng commonalities and differences.=C2=A0
  • I put together a presentation summarizing my findings and suggesting a = rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/ber= tocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Sk= okan on it. Thx Filip!
  • The presentati= on was followed up by 1.5 hours of unconference discussion, which was incre= dibly valuable to get tight-loop feedback and incorporate new ideas. John B= radley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=C2=A0Nat Sa= kimura, Hannes Tschofenig=C2=A0were all there and contributed generously to= the discussion. Thank you!!!
    Note: if you were at OSW2019, participated= in the discussion and didn't get credited in the draft, my apologies: = please send me a note and I'll make things right at the next update.=
  • On my flight back I did my best to inco= rporate all the ideas and feedback in a draft, which will be discussed at I= ETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful = in negotiating the mysterious syntax of the RFC format and submission proce= ss.

    • I was blown away by th= e availability, involvement and willingness to invest time to get things ri= ght that everyone demonstrated in the process. This is an amazing community= .=C2=A0

    V.

    __________________________= _____________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/l= istinfo/oauth

    =C2=A0

    ______________________= _________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailm= an/listinfo/oauth

    _______________________________________________
    OAuth mail= ing list
    OAuth@ietf.= org
    https://www.ietf.org/mailman/listinfo/oauth


    =C2=A0

    -= -

    --000000000000c920a30584f42fb5-- From nobody Mon Mar 25 17:34:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBC812018A for ; Mon, 25 Mar 2019 17:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OLUtUaY0jinK for ; Mon, 25 Mar 2019 17:34:53 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C6F12018B for ; Mon, 25 Mar 2019 17:34:53 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id b12so7415264pgk.0 for ; Mon, 25 Mar 2019 17:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IiQMSC8LGPS7/WFu4/XoMzhvoRNhN4GnAXnTIoXR9Ac=; b=lrtIlVJD1SF5M/bEJsZst2V/giAjkZ1XeLQ7Ug0gQ6gruMaTiqRzt8by/HVZ9005BZ oPSr6RSqDVAAbRXPsMNX1tNUp8wPhawqB96Ua7mft5Zszdshneas9J537bpyK1oVhSfK y4gHE7LZFxE6SNIfJxyfBa50UxhS1hXxGe7NDkTiiMSf6HJpZ83aXDcIsqt9D/nnU7W/ kNq9XSkY61NLmcn/JQCteGTbnv6OVETHj+s4bn/nlscwp8qbULN26SGS17oq8ug+IGiS NyyAs7rNKdCcBCsiVCKxysCpmJw5MsqqfHo3G7CTDIpIV3YUOsVi/oZNU7UzrNGRBWz7 ajyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IiQMSC8LGPS7/WFu4/XoMzhvoRNhN4GnAXnTIoXR9Ac=; b=GuTHwRj61KK/Fs0ozlXzQqBoETS8sjts0xcl9K72lEDeJoqaBcujIYNFPu7dhW1XFg 4VEjIn2N1IP1Dy+o2tJlYyCDBysaahiiTG8x+1OEqIEd/GawL5M3JRoGrZOejD3EWZtd k4NFT6F9gJfFUfTxB5GhsvVrolyfn+OzBtDy2T+mFGgxDylgrmuhzrzYazib0lu/NARe v/qMdtGb/SXUfqfMTW3vCbiteOYcA1urM3Gb98nu5jf6+kBQ3cVSDhtT9bAcmIjpIMwo jgdj9CV8kr/8s5UZ0te/v3y8yKWvCVXnUTf4nEAFcUfSzMuAOvncvBRgacbh9XlQ+qrG KCyw== X-Gm-Message-State: APjAAAXATlzX2OIO4vDf7CvU1zVSRgmTJc/ghLsU9sbR70uYB78Pw2gJ +xyChLQK6Qhtn2Lsw0iuIzc= X-Google-Smtp-Source: APXvYqwSAv+lDoa/krpsQ2fFVW8YbBMPpTfNgD0EOBmI8iuSb/NUmZfE2hf/bEGR3BZedotatNH24w== X-Received: by 2002:a63:db14:: with SMTP id e20mr2604317pgg.437.1553560492960; Mon, 25 Mar 2019 17:34:52 -0700 (PDT) Received: from ?IPv6:2001:240:2419:f1df:cccb:4f0:9a88:d56? ([2001:240:2419:f1df:cccb:4f0:9a88:d56]) by smtp.gmail.com with ESMTPSA id k75sm41130085pfj.46.2019.03.25.17.34.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 17:34:51 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-98060D07-D6FE-4E2B-8A6E-903B9D8CCB93 Mime-Version: 1.0 (1.0) From: Nov Matake X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Tue, 26 Mar 2019 09:34:49 +0900 Cc: Hans Zandbelt , Dominick Baier , IETF oauth WG Content-Transfer-Encoding: 7bit Message-Id: References: To: Vittorio Bertocci Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 00:34:56 -0000 --Apple-Mail-98060D07-D6FE-4E2B-8A6E-903B9D8CCB93 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Vittorio, Yeah, I=E2=80=99m concerning user & client ids collision. I haven=E2=80=99t seen such implementations, but user-select username as sub= , or incremental integer as sub & client_id will be easily collide. If you can enforce collision resistant IDs between user & client instances, i= t=E2=80=99ll works fine. I feel its overkill though. Sent from my iPhone > On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote: >=20 > Hey Nov, Dominick, Hans- > thanks for the comments. That was an area I was expecting to cause more di= scussion, and I am glad we are having this opportunity to clarify. > The current language in the draft traces the etymology of sub to OpenID Co= nnect core, hence Dominick observation is on point. However in the descripti= on I express something in line with 7519, which was in fact my intent. >=20 > The idea was to provide an identifier of the calling subject that is guara= nteed to be present in all cases- this would allow an SDK developer to use t= he same code for things like lookups and membership checks regardless of the= nature of the caller (user in a delegated case, app in app-only grants). Th= e information to discriminate between user and app callers is always availab= le in the token (say, the caller is a user if sub!=3Dclient_id, where client= _id is always guaranteed to be present as well) hence there's no loss in exp= ressive power, should that difference be relevant for the resource server. >=20 > Dominick, Hans- I probably missed the security issue you guys are thinking= of in this case. Of course, if this would introduce a risk I completely agr= ee it should be changed- I'd just like to understand better the problem. Cou= ld you expand it in a scenario/use case to clarify the risk? > Nov- playing this back: is the concern that a user and a client might have= the same identifier within an IDP? When using collision resistant IDs, as i= t is usually the case, that seems to be a remote possibility- did you stumbl= e in such scenario in production? >=20 > Thanks > V.=20 >=20 >=20 >> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt wrote: >> I believe there are plenty of OAuth 2.0 only use cases out there... but n= evertheless I agree with the potential confusion and thus security problems a= rising from that (though one may argue the semantics are the same). >>=20 >> Hans. >>=20 >>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier wrote: >>> Yes I know - and I think in hindsight it was a mistake to use the same c= laim type for multiple semantics. >>>=20 >>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making th= ings more complicated than they need to be - in my experience almost no-one (= that I know) does OIDC only - nor OAuth only. They always combine it. >>>=20 >>> In reality this leads to potential security problems - this spec has the= potential to rectify the situation. >>>=20 >>> Dominick >>>=20 >>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.e= u) wrote: >>>>=20 >>>> Without agreeing or disagreeing: OIDC does not apply here since it is n= ot OAuth and an access token is not an id_token. >>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:= >>>>=20 >>>> "The "sub" (subject) claim identifies the principal that is the >>>> subject of the JWT. The claims in a JWT are normally statements >>>> about the subject. The subject value MUST either be scoped to be >>>> locally unique in the context of the issuer or be globally unique. >>>> The processing of this claim is generally application specific" >>>>=20 >>>> which kind of spells "client" in case of the client credentials grant b= ut I also do worry about Resource Servers thinking/acting only in terms of u= sers >>>>=20 >>>> Hans. >>>>=20 >>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier wrote: >>>>> IMHO the sub claim should always refer to the user - and nothing else.= >>>>>=20 >>>>> OIDC says: >>>>>=20 >>>>> "Subject - Identifier for the End-User at the Issuer." >>>>>=20 >>>>> client_id should be used to identify clients. >>>>>=20 >>>>> cheers >>>>> Dominick >>>>>=20 >>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>>>>>=20 >>>>>> Hi Vittorio, >>>>>>=20 >>>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>>>=20 >>>>>> One feedback. >>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, en= d-user and client, in this spec. >>>>>> It requires those 2 types of identifiers to be unique each other in t= he IdP context. >>>>>>=20 >>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so= that no such constraint needed. >>>>>>=20 >>>>>> thanks >>>>>>=20 >>>>>> nov >>>>>>=20 >>>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci wrote: >>>>>>>=20 >>>>>>> Dear all, >>>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 acce= ss tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocc= i-oauth-access-token-jwt/. >>>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenti= ng remotely). I look forward for your comments! >>>>>>>=20 >>>>>>> Here's just a bit of backstory, in case you are interested in how th= is doc came to be. The trajectory it followed is somewhat unusual. >>>>>>> Despite OAuth2 not requiring any specific format for ATs, through th= e years I have come across multiple proprietary solution using JWT for their= access token. The intent and scenarios addressed by those solutions are mos= tly the same across vendors, but the syntax and interpretations in the imple= mentations are different enough to prevent developers from reusing code and s= kills when moving from product to product. >>>>>>> I asked several individuals from key products and services to share w= ith me concrete examples of their JWT access tokens (THANK YOU Dominick Baie= r (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsof= t), Karl Guinness (Okta) for the tokens and explanations!). >>>>>>> I studied and compared all those instances, identifying commonalitie= s and differences.=20 >>>>>>> I put together a presentation summarizing my findings and suggesting= a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/= events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early fe= edback from Filip Skokan on it. Thx Filip! >>>>>>> The presentation was followed up by 1.5 hours of unconference discus= sion, which was incredibly valuable to get tight-loop feedback and incorpora= te new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodde= rstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed gener= ously to the discussion. Thank you!!! >>>>>>> Note: if you were at OSW2019, participated in the discussion and did= n't get credited in the draft, my apologies: please send me a note and I'll m= ake things right at the next update. >>>>>>> On my flight back I did my best to incorporate all the ideas and fee= dback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hanne= s and above all Brian were all super helpful in negotiating the mysterious s= yntax of the RFC format and submission process. >>>>>>> I was blown away by the availability, involvement and willingness to= invest time to get things right that everyone demonstrated in the process. T= his is an amazing community.=20 >>>>>>> V. >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> -- >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>=20 >>=20 >> --=20 >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu --Apple-Mail-98060D07-D6FE-4E2B-8A6E-903B9D8CCB93 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Hi Vittorio,

    Yeah, I=E2=80=99m conce= rning user & client ids collision.
    I haven=E2=80=99t seen such= implementations, but user-select username as sub, or incremental integer as= sub & client_id will be easily collide.

    If you= can enforce collision resistant IDs between user & client instances, it= =E2=80=99ll works fine. I feel its overkill though.

    Sent from my iPhone

    On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

    Hey Nov, Dominick, Hans-
    = thanks for the comments. That was an area I was expecting to cause more disc= ussion, and I am glad we are having this opportunity to clarify.
    T= he current language in the draft traces the etymology of sub to OpenID Conne= ct core, hence Dominick observation is on point. However in the description I= express something in line with 7519, which was in fact my intent.

    The idea was to provide an identifier of the calling subject= that is guaranteed to be present in all cases- this would allow an SDK deve= loper to use the same code for things like lookups and membership checks reg= ardless of the nature of the caller (user in a delegated case, app in app-on= ly grants). The information to discriminate between user and app callers is a= lways available in the token (say, the caller is a user if sub!=3Dclient_id,= where client_id is always guaranteed to be present as well) hence there's n= o loss in expressive power, should that difference be relevant for the resou= rce server.

    Dominick, Hans- I probably missed the s= ecurity issue you guys are thinking of in this case. Of course, if this woul= d introduce a risk I completely agree it should be changed- I'd just like to= understand better the problem. Could you expand it in a scenario/use case t= o clarify the risk?
    Nov- playing this back: is the concern that a u= ser and a client might have the same identifier within an IDP? When using co= llision resistant IDs, as it is usually the case, that seems to be a remote p= ossibility- did you stumble in such scenario in production?

    Thanks
    V. 


    On Mon, Mar 25, 2019 at 7= :44 AM Hans Zandbelt <hans.= zandbelt@zmartzone.eu> wrote:
    I believe there are ple= nty of OAuth 2.0 only use cases out there... but nevertheless I agree with t= he potential confusion and thus security problems arising from that (though o= ne may argue the semantics are the same).

    Han= s.

    On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com&g= t; wrote:
    Yes I know - and I th= ink in hindsight it was a mistake to use the same claim type for multiple se= mantics.

    =
    All the =E2=80= =9Cthis is OIDC not OAuth=E2=80=9D arguments are making things more complica= ted than they need to be - in my experience almost no-one (that I know) does= OIDC only - nor OAuth only. They always combine it.

    In reality this leads to potential security p= roblems - this spec has the potential to rectify the situation.
    <= br>
    Dominick

    On 25. March 2019 at 14:58:56, H= ans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

    Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.

    "The "sub" (subject) claim identifies the principal that is the
       subject of the JWT.  The claims in a JWT are normally statements
       about the subject.  The subject value MUST either be scoped to be
       locally unique in the context of the issuer or be globally unique.
       The processing of this claim is generally application specific"

    which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

    Hans.

    On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    IMHO the sub claim should always refer to the user - and nothing else.

    OIDC says:

    "Subject - Identifier for the End-User at the Issuer."

    client_id should be used to identify clients.

    cheers
    Dominick

    On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Thanks for the good starting point of standardizing JWT-ized AT.

    One feedback.
    The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier= , end-user and client, in this spec.
    It requires those 2 types of identifiers to be unique each other in the IdP context.

    I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context= , so that no such constraint needed.

    thanks

    nov
    On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.= bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
    Dear all,
    I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in h= ttps://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.<= /span>
    I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

    Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
    • Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
    • I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
      I studied and compared all those instances, identifying commonalities and differences. 
    • I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/= slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!
    • The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt,=  Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
      Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
    • On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
    I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 
    V.
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --


    --
    = --Apple-Mail-98060D07-D6FE-4E2B-8A6E-903B9D8CCB93-- From nobody Mon Mar 25 23:24:20 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1031202BB for ; Mon, 25 Mar 2019 23:24:03 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com 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 lZmRuLyxG0Vr for ; Mon, 25 Mar 2019 23:23:58 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2261202B8 for ; Mon, 25 Mar 2019 23:23:56 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id b74so6917142qkg.9 for ; Mon, 25 Mar 2019 23:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=P2ho1HsYme40dcxHWqZ0vqAPDuNKm/RvtqXS6WGAKfE=; b=lMjltAhCgwNRL8Hk7brF0ABTVGDpg5YXEL80/23htX2PPkfDmXEasLqPwrvLaHhruo H1b5YhKWPr01b/ds5kNQc3FKIIP84/iMzVQGyM3IN8G136OUVR9mYaIs/gqqlM7i2uyB FQjKsUBYY/+FFEFEqogO1pepa5JdEAP3YEiDzVpFTxlJezjVYRVanKCDwreuhKy4qMxN ocjZ9pbdJ4t+NE8q9pNtI8e7FKs+7vwJuEqPeLj98p5uva/x2L03w2oPTynenAcykqh+ rWeLMdxZff3GRPUHNStPsTyAi7Mp0n2TXjHeKn3zom4StoUN3AkpSVGP7JyXIEBOvkg+ Xa5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=P2ho1HsYme40dcxHWqZ0vqAPDuNKm/RvtqXS6WGAKfE=; b=P6vLD2wwkAgcUXgUfTeS7hqrq2Oi3j0rVRgbcVomoIW9vuZItLUavSR14a3ynvR69n nUevUzr+q6rlkM0Dpo7uEp0GubP5AgmFnAySZRhygwJrESmWytbfQK3KXbVkOnho4FuC 1egRufSw2xgde3YlG2Uo5TwGAp9FZiNTHhd56pra9Gr4yPokhEHgUX7N48q2dRkB4MEf i8gPt07fi2nqx5iOJF/ke6tXmvzu+KUXJZ5hpiIrFALD+7U+uktPwHwK5y2d4FSk2aTf a5kSkXi4J68S+wlHJjd4jD7kfHOx6Mjw6hEJcjm3//2MV9eZls9XU0nAHzuS80NQRxig ovTg== X-Gm-Message-State: APjAAAVDTu0SedeaHEOS4sd8T5XLUPa6mWaMFz2+DycyaiON6DFvvsuZ Qj/bNXcb+R5CO5KLhi1Xk09IkqH1cv3h3qEOW5Ts X-Google-Smtp-Source: APXvYqyoLwh/O1ERvE7A3GSA1oLRwK6XyiFg7gRVeYetXcM6xIA24tnhTKpRwdUW5jsAvEZ0P7kkU+RWeVgi8qEVWEI= X-Received: by 2002:a37:6484:: with SMTP id y126mr22796622qkb.186.1553581435116; Mon, 25 Mar 2019 23:23:55 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 25 Mar 2019 23:23:54 -0700 From: Dominick Baier In-Reply-To: References: MIME-Version: 1.0 Date: Mon, 25 Mar 2019 23:23:54 -0700 Message-ID: To: Nov Matake , Vittorio Bertocci Cc: IETF oauth WG , Hans Zandbelt Content-Type: multipart/alternative; boundary="00000000000091f4740584f95df3" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 06:24:12 -0000 --00000000000091f4740584f95df3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From an access token consumer (aka API) developer point of view, I prefer this logic "If sub is present - client acts on behalf of a user, if not - not." Anything more complicated has a potential of going wrong. On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: Hi Vittorio, Yeah, I=E2=80=99m concerning user & client ids collision. I haven=E2=80=99t seen such implementations, but user-select username as su= b, or incremental integer as sub & client_id will be easily collide. If you can enforce collision resistant IDs between user & client instances, it=E2=80=99ll works fine. I feel its overkill though. Sent from my iPhone On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote: Hey Nov, Dominick, Hans- thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify. The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent. The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_i= d, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server. Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk? Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production? Thanks V. On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt wrote: > I believe there are plenty of OAuth 2.0 only use cases out there... but > nevertheless I agree with the potential confusion and thus security > problems arising from that (though one may argue the semantics are the > same). > > Hans. > > On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier > wrote: > >> Yes I know - and I think in hindsight it was a mistake to use the same >> claim type for multiple semantics. >> >> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making th= ings more >> complicated than they need to be - in my experience almost no-one (that = I >> know) does OIDC only - nor OAuth only. They always combine it. >> >> In reality this leads to potential security problems - this spec has the >> potential to rectify the situation. >> >> Dominick >> >> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu= ) >> wrote: >> >> Without agreeing or disagreeing: OIDC does not apply here since it is no= t >> OAuth and an access token is not an id_token. >> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: >> >> "The "sub" (subject) claim identifies the principal that is the >> subject of the JWT. The claims in a JWT are normally statements >> about the subject. The subject value MUST either be scoped to be >> locally unique in the context of the issuer or be globally unique. >> The processing of this claim is generally application specific" >> >> which kind of spells "client" in case of the client credentials grant bu= t >> I also do worry about Resource Servers thinking/acting only in terms of >> users >> >> Hans. >> >> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier >> wrote: >> >>> IMHO the sub claim should always refer to the user - and nothing else. >>> >>> OIDC says: >>> >>> "Subject - Identifier for the End-User at the Issuer." >>> >>> client_id should be used to identify clients. >>> >>> cheers >>> Dominick >>> >>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>> >>> Hi Vittorio, >>> >>> Thanks for the good starting point of standardizing JWT-ized AT. >>> >>> One feedback. >>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end-= user and client, >>> in this spec. >>> It requires those 2 types of identifiers to be unique each other in the >>> IdP context. >>> >>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so t= hat no such >>> constraint needed. >>> >>> thanks >>> >>> nov >>> >>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>> >>> Dear all, >>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>> tokens. You can find it in >>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/= . >>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>> remotely). I look forward for your comments! >>> >>> Here's just a bit of backstory, in case you are interested in how this >>> doc came to be. The trajectory it followed is somewhat unusual. >>> >>> - Despite OAuth2 not requiring any specific format for ATs, through >>> the years I have come across multiple proprietary solution using JWT= for >>> their access token. The intent and scenarios addressed by those solu= tions >>> are mostly the same across vendors, but the syntax and interpretatio= ns in >>> the implementations are different enough to prevent developers from = reusing >>> code and skills when moving from product to product. >>> - I asked several individuals from key products and services to >>> share with me concrete examples of their JWT access tokens (THANK YO= U >>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and >>> explanations!). >>> I studied and compared all those instances, identifying >>> commonalities and differences. >>> - I put together a presentation summarizing my findings and >>> suggesting a rough interoperable profile (slides: >>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-= _a_jwt_profile_for_ats.pptx >>> >>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>> - The presentation was followed up by 1.5 hours of unconference >>> discussion, which was incredibly valuable to get tight-loop feedback= and >>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvin= ov, >>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>> and contributed generously to the discussion. Thank you!!! >>> Note: if you were at OSW2019, participated in the discussion and >>> didn't get credited in the draft, my apologies: please send me a not= e and >>> I'll make things right at the next update. >>> - On my flight back I did my best to incorporate all the ideas and >>> feedback in a draft, which will be discussed at IETF104 tomorrow. Ri= faat, >>> Hannes and above all Brian were all super helpful in negotiating the >>> mysterious syntax of the RFC format and submission process. >>> >>> I was blown away by the availability, involvement and willingness to >>> invest time to get things right that everyone demonstrated in the proce= ss. >>> This is an amazing community. >>> V. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> >> > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > --00000000000091f4740584f95df3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    From= an access token consumer (aka API) developer point of view, I prefer this = logic

    "If sub = is present - client acts on behalf of a user, if not - not."

    Anything more complicated h= as a potential of going wrong.


    On 26. March 2019 at 01:34:53, Nov Matake = (matake@gmail.com) wrote:

    =
    Hi Vittorio,

    Yeah, I=E2=80=99m concerning user & client ids collision.
    I haven=E2=80=99t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

    If you can enforce collision resistant IDs between user & client instances, it=E2=80=99ll works fine. I feel its overkill though.

    Sent from my iPhone

    On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

    Hey Nov, Dominick, Hans-
    thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
    The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

    The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

    Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
    Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

    Thanks
    V.=C2=A0


    On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbe= lt@zmartzone.eu> wrote:
    I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

    Hans.

    On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

    All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

    In reality this leads to potential security problems - this spec has the potential to rectify the situation.

    Dominick

    On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

    Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
    "The "sub" (subject) claim identifies the princip= al that is the
    =C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are normally statements
    =C2=A0 =C2=A0about the subject.=C2=A0 The subject value MUST either be scoped to be
    =C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
    =C2=A0 =C2=A0The processing of this claim is generally application specific"

    which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

    Hans.
    On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    IMHO the sub claim should always refer to the user - and nothing else.

    OIDC says:

    "Subject - Identifier for the End-User at the Issuer."

    client_id should be used to identify clients.

    cheers
    Dominick

    On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Thanks for the good starting point of standardizing JWT-ized AT.

    One feedback.
    The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
    It requires those 2 types of identifiers to be unique each other in the IdP context.

    I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

    thanks

    nov
    On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
    Dear all,
    I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
    I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

    Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
    I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
    V.
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --


    --
     --00000000000091f4740584f95df3-- From nobody Tue Mar 26 01:03:27 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4004F120047 for ; Tue, 26 Mar 2019 01:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 QVU9lS7AYlrk for ; Tue, 26 Mar 2019 01:03:21 -0700 (PDT) Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 24C7012028B for ; Tue, 26 Mar 2019 01:03:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FWAgDb25lc/xwBYJlaBAYbAQEBAQM?= =?us-ascii?q?BAQEHAwEBAYFlgWcqaIEDJwqEBGKCaIUxjC0lfog6jxeBZwoFGA0JgQKCdkY?= =?us-ascii?q?ChR0iOBIBAQMBAQkBAwICAmkcDIJ4MRw+AQEBAQEBJgEBAQEBAQEjAhQfESw?= =?us-ascii?q?BAQEDAQEBISYlCwULAgEIGCoCAiEGCyUCBA4FDgYHgwcBgV0DDQcBD60igS+?= =?us-ascii?q?Dc1FBQYJDDYIQD4EvgUmJaYFYPoERJwwTgU5JNT6CGkcBAQIBAYElDQ8GCEY?= =?us-ascii?q?GgkwxgiYDilyHH5JoNgMEAgKBJIM7gg9ziBmDPxmCAoV9gyGIYow0hG+BOog?= =?us-ascii?q?nAYNwgWQiKAmBJXFFCgUlAVUdgSYpCYINF4EAAQ6Cb06EE4U/PwEBMQEBjye?= =?us-ascii?q?BHwEB?= X-IPAS-Result: =?us-ascii?q?A2FWAgDb25lc/xwBYJlaBAYbAQEBAQMBAQEHAwEBAYFlg?= =?us-ascii?q?WcqaIEDJwqEBGKCaIUxjC0lfog6jxeBZwoFGA0JgQKCdkYChR0iOBIBAQMBA?= =?us-ascii?q?QkBAwICAmkcDIJ4MRw+AQEBAQEBJgEBAQEBAQEjAhQfESwBAQEDAQEBISYlC?= =?us-ascii?q?wULAgEIGCoCAiEGCyUCBA4FDgYHgwcBgV0DDQcBD60igS+Dc1FBQYJDDYIQD?= =?us-ascii?q?4EvgUmJaYFYPoERJwwTgU5JNT6CGkcBAQIBAYElDQ8GCEYGgkwxgiYDilyHH?= =?us-ascii?q?5JoNgMEAgKBJIM7gg9ziBmDPxmCAoV9gyGIYow0hG+BOognAYNwgWQiKAmBJ?= =?us-ascii?q?XFFCgUlAVUdgSYpCYINF4EAAQ6Cb06EE4U/PwEBMQEBjyeBHwEB?= X-IronPort-AV: E=Sophos; i="5.60,271,1549926000"; d="asc'?scan'208"; a="9978039" Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2019 09:03:14 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdBQDb25lcfRBhWMBaBAYcAQEBBAE?= =?us-ascii?q?BBwQBAYFlgWeBElAhEicKhARiiBmMLSV+iDqPF4FnCgUYDYQBRgKFPjgSAQE?= =?us-ascii?q?DAQEJAQMCFAEBFjojDIVKAQEBAwEBASEmJQsFCwIBCBgqAgIhBgslAgQOBQ4?= =?us-ascii?q?GB4MHAYFdAw0ID60igS+EREFBgkMNghAPgS+BSYtBPoERJwwTgU5JNT6CGkc?= =?us-ascii?q?BAQIBAYElDQ8GCEYGgkwxgiYDilyHH5JoNgMEAgKBJIM7gg9ziBmDPxmCAoV?= =?us-ascii?q?9gyGIYow0hG+BOowYgWQgKQmBJXFFCgUlAVUdgSYpCYINF4EAAQ6Cb06EE4U?= =?us-ascii?q?/PwECMAEBjyeBHwEB?= X-IronPort-AV: E=Sophos;i="5.60,271,1549926000"; d="asc'?scan'208";a="19630561" Received: from fgdemucivp01ltm.xch.fraunhofer.de (HELO FGDEMUCIMP12EXC.ads.fraunhofer.de) ([192.88.97.16]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/AES256-SHA; 26 Mar 2019 09:03:14 +0100 Received: from FGDEMUCIMP02EXC.ads.fraunhofer.de ([10.80.232.41]) by FGDEMUCIMP12EXC.ads.fraunhofer.de ([10.80.232.43]) with mapi id 14.03.0435.000; Tue, 26 Mar 2019 09:03:13 +0100 From: "Schanzenbach, Martin" To: Vittorio Bertocci CC: Hans Zandbelt , IETF oauth WG Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 Thread-Index: AQHU42Wr/thS5xrVIYxSuUg+/ebS0aYdfSgA Date: Tue, 26 Mar 2019 08:03:13 +0000 Message-ID: <0485843D-5534-48C3-8F17-0BD092615217@aisec.fraunhofer.de> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.80.233.51] x-tm-as-product-ver: SMEX-11.0.0.4179-8.200.1013-24510.005 x-tm-as-result: No--32.491000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_55FF7529-BA4C-4903-8178-52D0138D9543"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 08:03:25 -0000 --Apple-Mail=_55FF7529-BA4C-4903-8178-52D0138D9543 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, first time posting here but I have a comment on the "sub" claim: We use RFC7523 for client authentication in a machine to machine = scenario (i.e. client credentials grant). In this RFC, the JWT used as client assertion is defined that it "MUST = contain a "sub" (subject) claim identifying the principal that is the = subject of the JWT" (Section 3). Now, we also issue JWT access tokens which look already very similar to = what is proposed in this draft. As an implementer of an AS, I would find it a bit odd that I need to add = the "sub" client with client_id for the self-signed assertion JWT on = token request, but it is then not included in the JWT issued by the AS. Regarding our application-specific claims in the JWT access token issued = by the AS, the interpretation of the "sub" claim should not change imho. BR Martin > On 26. Mar 2019, at 00:51, Vittorio Bertocci = wrote: >=20 > Hey Nov, Dominick, Hans- > thanks for the comments. That was an area I was expecting to cause = more discussion, and I am glad we are having this opportunity to = clarify. > The current language in the draft traces the etymology of sub to = OpenID Connect core, hence Dominick observation is on point. However in = the description I express something in line with 7519, which was in fact = my intent. >=20 > The idea was to provide an identifier of the calling subject that is = guaranteed to be present in all cases- this would allow an SDK developer = to use the same code for things like lookups and membership checks = regardless of the nature of the caller (user in a delegated case, app in = app-only grants). The information to discriminate between user and app = callers is always available in the token (say, the caller is a user if = sub!=3Dclient_id, where client_id is always guaranteed to be present as = well) hence there's no loss in expressive power, should that difference = be relevant for the resource server.. >=20 > Dominick, Hans- I probably missed the security issue you guys are = thinking of in this case. Of course, if this would introduce a risk I = completely agree it should be changed- I'd just like to understand = better the problem. Could you expand it in a scenario/use case to = clarify the risk? > Nov- playing this back: is the concern that a user and a client might = have the same identifier within an IDP? When using collision resistant = IDs, as it is usually the case, that seems to be a remote possibility- = did you stumble in such scenario in production? >=20 > Thanks > V. >=20 >=20 > On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt = wrote: > I believe there are plenty of OAuth 2.0 only use cases out there... = but nevertheless I agree with the potential confusion and thus security = problems arising from that (though one may argue the semantics are the = same). >=20 > Hans. >=20 > On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = wrote: > Yes I know - and I think in hindsight it was a mistake to use the same = claim type for multiple semantics. >=20 > All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making = things more complicated than they need to be - in my experience almost = no-one (that I know) does OIDC only - nor OAuth only. They always = combine it. >=20 > In reality this leads to potential security problems - this spec has = the potential to rectify the situation. >=20 > Dominick >=20 > On 25. March 2019 at 14:58:56, Hans Zandbelt = (hans.zandbelt@zmartzone.eu) wrote: >=20 >> Without agreeing or disagreeing: OIDC does not apply here since it is = not OAuth and an access token is not an id_token. >> The JWT spec says in = https://tools.ietf.org/html/rfc7519#section-4.1.2: >>=20 >> "The "sub" (subject) claim identifies the principal that is the >> subject of the JWT. The claims in a JWT are normally statements >> about the subject. The subject value MUST either be scoped to be >> locally unique in the context of the issuer or be globally unique. >> The processing of this claim is generally application specific" >>=20 >> which kind of spells "client" in case of the client credentials grant = but I also do worry about Resource Servers thinking/acting only in terms = of users >>=20 >> Hans. >>=20 >> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = wrote: >> IMHO the sub claim should always refer to the user - and nothing = else. >>=20 >> OIDC says: >>=20 >> "Subject - Identifier for the End-User at the Issuer." >>=20 >> client_id should be used to identify clients. >>=20 >> cheers >> Dominick >>=20 >> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>=20 >>> Hi Vittorio, >>>=20 >>> Thanks for the good starting point of standardizing JWT-ized AT. >>>=20 >>> One feedback. >>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and client, in this spec. >>> It requires those 2 types of identifiers to be unique each other in = the IdP context. >>>=20 >>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, = so that no such constraint needed. >>>=20 >>> thanks >>>=20 >>> nov >>>=20 >>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci = wrote: >>>>=20 >>>> Dear all, >>>> I just submitted a draft describing a JWT profile for OAuth 2.0 = access tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be = presenting remotely). I look forward for your comments! >>>>=20 >>>> Here's just a bit of backstory, in case you are interested in how = this doc came to be. The trajectory it followed is somewhat unusual. >>>> =E2=80=A2 Despite OAuth2 not requiring any specific format for = ATs, through the years I have come across multiple proprietary solution = using JWT for their access token. The intent and scenarios addressed by = those solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. >>>> =E2=80=A2 I asked several individuals from key products and = services to share with me concrete examples of their JWT access tokens = (THANK YOU Dominick Baier (IdentityServer), Brian Campbell = (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for = the tokens and explanations!). >>>> I studied and compared all those instances, identifying = commonalities and differences. >>>> =E2=80=A2 I put together a presentation summarizing my findings = and suggesting a rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. = Thx Filip! >>>> =E2=80=A2 The presentation was followed up by 1.5 hours of = unconference discussion, which was incredibly valuable to get tight-loop = feedback and incorporate new ideas. John Bradley, Brian Campbell = Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig = were all there and contributed generously to the discussion. Thank = you!!! >>>> Note: if you were at OSW2019, participated in the discussion and = didn't get credited in the draft, my apologies: please send me a note = and I'll make things right at the next update. >>>> =E2=80=A2 On my flight back I did my best to incorporate all the = ideas and feedback in a draft, which will be discussed at IETF104 = tomorrow. Rifaat, Hannes and above all Brian were all super helpful in = negotiating the mysterious syntax of the RFC format and submission = process. >>>> I was blown away by the availability, involvement and willingness = to invest time to get things right that everyone demonstrated in the = process. This is an amazing community. >>>> V. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >=20 >=20 > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Martin Schanzenbach Fraunhofer AISEC Department Service & Application Security Parkring 4, 85748 Garching near Munich (Germany) Tel: +49 89 3229986-193 martin.schanzenbach@aisec.fraunhofer.de GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 --Apple-Mail=_55FF7529-BA4C-4903-8178-52D0138D9543 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEZmUgHqklfMaP3nfohDNRMeo9q/AFAlyZ3MAACgkQhDNRMeo9 q/Dq1BAAmMK0713a7/0lNYHGTPbvHxKRbVnKzugeaxrEyTaQXVRSURJCzRBVNMJj sdKUd0DYDFU9XTQzxwXPJalDuOVoRcSas/ERW76Blxw78/vBzm6Mbv5IlprJgbhK 4mgivkvrEcaKdRPW3s8oF5tCtT1zDNgoSGkLhz6oOnG+CYRqDpZ+tvzQj9HuRYPS ZWHpDjplLeg6yDJLrrcmUcb2vBftRHaAGRk1LKp8VB41sVWG8oe2LkYUvDHPtH+n psMvML4f4SbImq7be/moDUHKPA9WNo9EeO45T6UPhIVIMt9kk/XRx5QKWB0seRFa SRoZscIgCZJIwhETlR3W6+Qyaydk8LI+q///gHGuPakpIZDsINx717yWNvnol0Y2 zdXp3ncRD8bQ2LhbdbUOVigMt+M14eM+Zr1kM2aVvxaWiGyNAwauHhiQ+WdrvdEr 2GG+sn9v9KcvTmhdRjHWlzlKl8RzD8zdxtRsTCrWyy1KLpelfrDV2l7H7V55Eejl YSqS1qmZ044U7zFfvxymcnAZWbs8/6Lq+TX+0YhYgrhCgOCoLNHZ7W+qquv3V+HY zX7l3QYC1n7DXhKZHlCyYgkrVYwK47l1s3Ef2PvWpHO2oK0peCnOSnyA+zkvZ2m9 9VvE/QJj2lJ6H5a4eaf6RaXqvw/kpWIUQnzkQMjq6vJqx5QgjcU= =H+97 -----END PGP SIGNATURE----- --Apple-Mail=_55FF7529-BA4C-4903-8178-52D0138D9543-- From nobody Tue Mar 26 01:27:08 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48E0120291 for ; Tue, 26 Mar 2019 01:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk 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 LNNXqwdjelru for ; Tue, 26 Mar 2019 01:26:58 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A57120292 for ; Tue, 26 Mar 2019 01:26:57 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id v13so10298645ljk.4 for ; Tue, 26 Mar 2019 01:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vlFiXU2NO6nGXr0X2HXVz3rtyRTBwtos3g08HZHfa6Q=; b=S1eWcWT1CW4y0JQi+PsPzyBpUatkA/GXsMl8oFWJXvlALpLqHYzM+3roq3WhksMdqv EN8jankGAk/koso6EMLy4n/8LMaO20iPcWgi7Ryv47YZrGfdEp/24AqWCWP4di2YQQcT yvKkUFU+qc9SUoAozlbUsDmVbBdScQqEXz+nI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vlFiXU2NO6nGXr0X2HXVz3rtyRTBwtos3g08HZHfa6Q=; b=dAC6bA6sMbQS2beUaAbkwti/yo8t4uG0I3pHt1WDxI7XuBoC+C3OLuwODaq9UmVL7N u5BhQ2kydyPYeaY4WQXS9INgabOcxjh59X0QCN9bGCiIjMB6UnOy01dWQsAHfaSmrbMf mHzeP8q/yNgYaifWMMha2apK7UYuZtf4/Bnu7d6CPJyURtnFgjHzXBpga5VFZu61VmBU fdCAQU4jthqOW+GN9cSlhiRO3lqO2UEspsIQ8D0oFnIqvMdRsWxoGBJwWa1UyCw0ezsu flxu3nZEknJ+QdxrHj3S1dsMO69s39hRAGdwgN/3OsLeMRm1UhuMx0q424DRDj+u+d38 Fsfw== X-Gm-Message-State: APjAAAXmtIdZFhjvIpvDtOKYgf2zlexAC+WaXD8RHArWjwMxqgNuVisa KDNSCOdm9dVxEitt2IGGkqIRO3Wj3yhfxqJFrjWjgg== X-Google-Smtp-Source: APXvYqwFKeIyCBr+TKEI4ikB8ITG5vdxif9XAyuSK7rFRV9sO4VM+7FZmgHjXcuPJs6YxzpyOc+2F3mTr16IIA+ifyg= X-Received: by 2002:a2e:93cf:: with SMTP id p15mr16019236ljh.184.1553588815471; Tue, 26 Mar 2019 01:26:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Tonge Date: Tue, 26 Mar 2019 09:26:44 +0100 Message-ID: To: Dominick Baier Cc: Nov Matake , Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000007949fb0584fb15de" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 08:27:06 -0000 --0000000000007949fb0584fb15de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Vittorio for your presentation and putting this draft together. I agree with Dominck that there is a potential of things going wrong when `sub` has multiple meanings. However I can see that using `sub` for a client_id semantically makes sense in some situations and I agree that it makes it simpler from an SDK point of view for there to always be a `sub`. My suggestion would be that either there is an explicit type to differentiate between "user access tokens" and "application access tokens", or failing that the `sub` is used to indicate the difference. Furthermore an agreement on the naming and description of these two types of access tokens would be helpful more generally. Dave On Tue, 26 Mar 2019 at 07:25, Dominick Baier wrote: > From an access token consumer (aka API) developer point of view, I prefer > this logic > > "If sub is present - client acts on behalf of a user, if not - not." > > Anything more complicated has a potential of going wrong. > > > On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: > > Hi Vittorio, > > Yeah, I=E2=80=99m concerning user & client ids collision. > I haven=E2=80=99t seen such implementations, but user-select username as = sub, or > incremental integer as sub & client_id will be easily collide. > > If you can enforce collision resistant IDs between user & client > instances, it=E2=80=99ll works fine. I feel its overkill though. > > Sent from my iPhone > > On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote: > > Hey Nov, Dominick, Hans- > thanks for the comments. That was an area I was expecting to cause more > discussion, and I am glad we are having this opportunity to clarify. > The current language in the draft traces the etymology of sub to OpenID > Connect core, hence Dominick observation is on point. However in the > description I express something in line with 7519, which was in fact my > intent. > > The idea was to provide an identifier of the calling subject that is > guaranteed to be present in all cases- this would allow an SDK developer = to > use the same code for things like lookups and membership checks regardles= s > of the nature of the caller (user in a delegated case, app in app-only > grants). The information to discriminate between user and app callers is > always available in the token (say, the caller is a user if sub!=3Dclient= _id, > where client_id is always guaranteed to be present as well) hence there's > no loss in expressive power, should that difference be relevant for the > resource server. > > Dominick, Hans- I probably missed the security issue you guys are thinkin= g > of in this case. Of course, if this would introduce a risk I completely > agree it should be changed- I'd just like to understand better the proble= m. > Could you expand it in a scenario/use case to clarify the risk? > Nov- playing this back: is the concern that a user and a client might hav= e > the same identifier within an IDP? When using collision resistant IDs, as > it is usually the case, that seems to be a remote possibility- did you > stumble in such scenario in production? > > Thanks > V. > > > On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt > wrote: > >> I believe there are plenty of OAuth 2.0 only use cases out there... but >> nevertheless I agree with the potential confusion and thus security >> problems arising from that (though one may argue the semantics are the >> same). >> >> Hans. >> >> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier >> wrote: >> >>> Yes I know - and I think in hindsight it was a mistake to use the same >>> claim type for multiple semantics. >>> >>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making t= hings more >>> complicated than they need to be - in my experience almost no-one (that= I >>> know) does OIDC only - nor OAuth only. They always combine it. >>> >>> In reality this leads to potential security problems - this spec has th= e >>> potential to rectify the situation. >>> >>> Dominick >>> >>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.e= u) >>> wrote: >>> >>> Without agreeing or disagreeing: OIDC does not apply here since it is >>> not OAuth and an access token is not an id_token. >>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: >>> >>> "The "sub" (subject) claim identifies the principal that is the >>> subject of the JWT. The claims in a JWT are normally statements >>> about the subject. The subject value MUST either be scoped to be >>> locally unique in the context of the issuer or be globally unique. >>> The processing of this claim is generally application specific" >>> >>> which kind of spells "client" in case of the client credentials grant >>> but I also do worry about Resource Servers thinking/acting only in term= s of >>> users >>> >>> Hans. >>> >>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>> dbaier@leastprivilege.com> wrote: >>> >>>> IMHO the sub claim should always refer to the user - and nothing else. >>>> >>>> OIDC says: >>>> >>>> "Subject - Identifier for the End-User at the Issuer." >>>> >>>> client_id should be used to identify clients. >>>> >>>> cheers >>>> Dominick >>>> >>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>>> >>>> Hi Vittorio, >>>> >>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>> >>>> One feedback. >>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end= -user and client, >>>> in this spec. >>>> It requires those 2 types of identifiers to be unique each other in th= e >>>> IdP context. >>>> >>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so = that no such >>>> constraint needed. >>>> >>>> thanks >>>> >>>> nov >>>> >>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>>> >>>> Dear all, >>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>>> tokens. You can find it in >>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt= / >>>> . >>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>>> remotely). I look forward for your comments! >>>> >>>> Here's just a bit of backstory, in case you are interested in how this >>>> doc came to be. The trajectory it followed is somewhat unusual. >>>> >>>> - Despite OAuth2 not requiring any specific format for ATs, through >>>> the years I have come across multiple proprietary solution using JW= T for >>>> their access token. The intent and scenarios addressed by those sol= utions >>>> are mostly the same across vendors, but the syntax and interpretati= ons in >>>> the implementations are different enough to prevent developers from= reusing >>>> code and skills when moving from product to product. >>>> - I asked several individuals from key products and services to >>>> share with me concrete examples of their JWT access tokens (THANK Y= OU >>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens an= d >>>> explanations!). >>>> I studied and compared all those instances, identifying >>>> commonalities and differences. >>>> - I put together a presentation summarizing my findings and >>>> suggesting a rough interoperable profile (slides: >>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_= -_a_jwt_profile_for_ats.pptx >>>> >>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>> - The presentation was followed up by 1.5 hours of unconference >>>> discussion, which was incredibly valuable to get tight-loop feedbac= k and >>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvi= nov, >>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>>> and contributed generously to the discussion. Thank you!!! >>>> Note: if you were at OSW2019, participated in the discussion and >>>> didn't get credited in the draft, my apologies: please send me a no= te and >>>> I'll make things right at the next update. >>>> - On my flight back I did my best to incorporate all the ideas and >>>> feedback in a draft, which will be discussed at IETF104 tomorrow. R= ifaat, >>>> Hannes and above all Brian were all super helpful in negotiating th= e >>>> mysterious syntax of the RFC format and submission process. >>>> >>>> I was blown away by the availability, involvement and willingness to >>>> invest time to get things right that everyone demonstrated in the proc= ess. >>>> This is an amazing community. >>>> V. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >>> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- --0000000000007949fb0584fb15de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks Vittorio for your presentation and= putting this draft together.

    I agree with Dominck that ther= e is a potential of things going wrong when `sub` has multiple meanings.
    However I can see that using `sub` for a client_id semantically makes se= nse in some situations and I agree that it makes it simpler from an SDK poi= nt of view for there to always be a `sub`.

    My suggestion wou= ld be that either there is an explicit type to differentiate between "= user access tokens" and "application access tokens", or fail= ing that the `sub` is used to indicate the difference.

    Furth= ermore an agreement on the naming and description of these two types of acc= ess tokens would be helpful more generally.

    Dave
    =
    On Tue= , 26 Mar 2019 at 07:25, Dominick Baier <dbaier@leastprivilege.com> wrote:
    From an access token consumer (aka API) developer= point of view, I prefer this logic

    "If sub is present - client acts on behalf of a user,= if not - not."

    Anything more complicated has a potential of going wrong.


    On 26. March 2019 at 01:34:53, = Nov Matake (matake@gm= ail.com) wrote:

    Hi Vittorio,

    Yeah, I=E2=80=99m concerning user & client ids collision.
    I haven=E2=80=99t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

    If you can enforce collision resistant IDs between user & client instances, it=E2=80=99ll works fine. I feel its overkill though.

    Sent= from my iPhone

    On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

    Hey Nov, Dominick, Hans-
    thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
    The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

    The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

    Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
    Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

    Thanks
    V.=C2=A0


    On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
    I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

    Hans.

    On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

    All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

    In reality this leads to potential security problems - this spec has the potential to rectify the situation.

    Dominick

    On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

    Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
    "The "sub" (subject) claim identifies the princip= al that is the
    =C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are normally statements
    =C2=A0 =C2=A0about the subject.=C2=A0 The subject value MUST either be scoped to be
    =C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
    =C2=A0 =C2=A0The processing of this claim is generally application specific"

    which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

    Hans.
    On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    IMHO the sub claim should always refer to the user - and nothing else.

    OIDC says:

    "Subject - Identifier for the End-User at the Issuer."

    client_id should be used to identify clients.

    cheers
    Dominick

    On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Thanks for the good starting point of standardizing JWT-ized AT.

    One feedback.
    The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
    It requires those 2 types of identifiers to be unique each other in the IdP context.

    I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

    thanks

    nov
    On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
    Dear all,
    I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
    I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

    Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
    I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
    V.
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --


    --
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --

    =
    --0000000000007949fb0584fb15de-- From nobody Tue Mar 26 01:40:02 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F4B120284 for ; Tue, 26 Mar 2019 01:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 WFZ4Lbl4zgIL for ; Tue, 26 Mar 2019 01:39:50 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB3D1202F2 for ; Tue, 26 Mar 2019 01:39:50 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id c8so7743253pfd.10 for ; Tue, 26 Mar 2019 01:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ov8JZDhX8WdBNW/K31qKeVIVDYFmnxbVhBOIFP1J7qo=; b=BQtgVhIVX9zMuFrNrEPgkP0prOQT96uXyAY7XzB4AhkHIeA/4uKfNWpZYE4wN2u/oT p6ZwdpIFvgd8yJSiPmTNFHfOjsNrRFnKH1IE5+ylegJ2Z9mUcTTTyAE7A8LNcayEdud0 zLIskQC1cI9O6DZhcIcKJu/Pqrv8x+qwJYVR0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ov8JZDhX8WdBNW/K31qKeVIVDYFmnxbVhBOIFP1J7qo=; b=WXjMmmRXQMbuGdlcspRplO47+bytuli3lIPwgb60T9sF4ZiRyzgGGg2HBohhA/PAPQ PzieRFkxjICBs8zCSUGIau4DUXR0lo321km3IVUIXWUjOQBTE3JsovddDZjJpQFj7tlG fGV1oqNBB3LNd+mcgTW1RaWTyzIZW2ppu+Q+ca37BvWHJ5vWdTKo1KdFYkw2HqRca8oN 7hiv4FuuCa8fU4/CK+PONK/02VOsrSrBWF3f8+YW7faF9orkZIWbmD34iCmwFUhZvgcM 9QGT5BZ+ZyE9FdAA7KUHftm26qyc+LEf9BqV49X03c+E15Boq711KUZhN389lqSIBp55 Fzrg== X-Gm-Message-State: APjAAAVTTJRMPgaNU37NUAbBFiMG865qVOTsE24+LzJwKpK1wI0wL/10 xgsDvEVZbZ+oJicPLK1kIVzSZYPWdy9VfS1gwI1GXreg7/0XVWwcnJ6u1glD0AIrIjMRRHJ5Itk M8UwZlcqU8csxVw== X-Google-Smtp-Source: APXvYqz44Q186i92h8Gy1wu8ixA6VFb+VWmuvNvVXzORfTiVecgzPZRnKFzvBRln58pb1LufVwHt0BsNwBL1wZdTrJ4= X-Received: by 2002:a63:69c2:: with SMTP id e185mr27330523pgc.4.1553589589993; Tue, 26 Mar 2019 01:39:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Otto Date: Tue, 26 Mar 2019 08:39:39 +0000 Message-ID: To: Dave Tonge Cc: Dominick Baier , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000a383b70584fb4329" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 08:39:59 -0000 --000000000000a383b70584fb4329 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99d like to add my support for not proposing any change to how sub = is typically interpreted for client credentials tokens. In my experience the usage of the client_id as the subject in this flow is well established and it would cause disruption to many current implementations should that be changed Best regards Rob On Tue, 26 Mar 2019 at 08:27, Dave Tonge wrote: > Thanks Vittorio for your presentation and putting this draft together. > > I agree with Dominck that there is a potential of things going wrong when > `sub` has multiple meanings. > However I can see that using `sub` for a client_id semantically makes > sense in some situations and I agree that it makes it simpler from an SDK > point of view for there to always be a `sub`. > > My suggestion would be that either there is an explicit type to > differentiate between "user access tokens" and "application access tokens= ", > or failing that the `sub` is used to indicate the difference. > > Furthermore an agreement on the naming and description of these two types > of access tokens would be helpful more generally. > > Dave > > On Tue, 26 Mar 2019 at 07:25, Dominick Baier > wrote: > >> From an access token consumer (aka API) developer point of view, I prefe= r >> this logic >> >> "If sub is present - client acts on behalf of a user, if not - not." >> >> Anything more complicated has a potential of going wrong. >> >> >> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >> >> Hi Vittorio, >> >> Yeah, I=E2=80=99m concerning user & client ids collision. >> I haven=E2=80=99t seen such implementations, but user-select username as= sub, or >> incremental integer as sub & client_id will be easily collide. >> >> If you can enforce collision resistant IDs between user & client >> instances, it=E2=80=99ll works fine. I feel its overkill though. >> >> Sent from my iPhone >> >> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote: >> >> Hey Nov, Dominick, Hans- >> thanks for the comments. That was an area I was expecting to cause more >> discussion, and I am glad we are having this opportunity to clarify. >> The current language in the draft traces the etymology of sub to OpenID >> Connect core, hence Dominick observation is on point. However in the >> description I express something in line with 7519, which was in fact my >> intent. >> >> The idea was to provide an identifier of the calling subject that is >> guaranteed to be present in all cases- this would allow an SDK developer= to >> use the same code for things like lookups and membership checks regardle= ss >> of the nature of the caller (user in a delegated case, app in app-only >> grants). The information to discriminate between user and app callers is >> always available in the token (say, the caller is a user if sub!=3Dclien= t_id, >> where client_id is always guaranteed to be present as well) hence there'= s >> no loss in expressive power, should that difference be relevant for the >> resource server. >> >> Dominick, Hans- I probably missed the security issue you guys are >> thinking of in this case. Of course, if this would introduce a risk I >> completely agree it should be changed- I'd just like to understand bette= r >> the problem. Could you expand it in a scenario/use case to clarify the r= isk? >> Nov- playing this back: is the concern that a user and a client might >> have the same identifier within an IDP? When using collision resistant I= Ds, >> as it is usually the case, that seems to be a remote possibility- did yo= u >> stumble in such scenario in production? >> >> Thanks >> V. >> >> >> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt >> wrote: >> >>> I believe there are plenty of OAuth 2.0 only use cases out there... but >>> nevertheless I agree with the potential confusion and thus security >>> problems arising from that (though one may argue the semantics are the >>> same). >>> >>> Hans. >>> >>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier < >>> dbaier@leastprivilege.com> wrote: >>> >>>> Yes I know - and I think in hindsight it was a mistake to use the same >>>> claim type for multiple semantics. >>>> >>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making = things more >>>> complicated than they need to be - in my experience almost no-one (tha= t I >>>> know) does OIDC only - nor OAuth only. They always combine it. >>>> >>>> In reality this leads to potential security problems - this spec has >>>> the potential to rectify the situation. >>>> >>>> Dominick >>>> >>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ( >>>> hans.zandbelt@zmartzone.eu) wrote: >>>> >>>> Without agreeing or disagreeing: OIDC does not apply here since it is >>>> not OAuth and an access token is not an id_token. >>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2= : >>>> >>>> "The "sub" (subject) claim identifies the principal that is the >>>> subject of the JWT. The claims in a JWT are normally statements >>>> about the subject. The subject value MUST either be scoped to be >>>> locally unique in the context of the issuer or be globally unique. >>>> The processing of this claim is generally application specific" >>>> >>>> which kind of spells "client" in case of the client credentials grant >>>> but I also do worry about Resource Servers thinking/acting only in ter= ms of >>>> users >>>> >>>> Hans. >>>> >>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>>> dbaier@leastprivilege.com> wrote: >>>> >>>>> IMHO the sub claim should always refer to the user - and nothing else= . >>>>> >>>>> OIDC says: >>>>> >>>>> "Subject - Identifier for the End-User at the Issuer." >>>>> >>>>> client_id should be used to identify clients. >>>>> >>>>> cheers >>>>> Dominick >>>>> >>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>>>> >>>>> Hi Vittorio, >>>>> >>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>> >>>>> One feedback. >>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, en= d-user and >>>>> client, in this spec. >>>>> It requires those 2 types of identifiers to be unique each other in >>>>> the IdP context. >>>>> >>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so= that no such >>>>> constraint needed. >>>>> >>>>> thanks >>>>> >>>>> nov >>>>> >>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>>>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>>>> >>>>> Dear all, >>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 acces= s >>>>> tokens. You can find it in >>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jw= t/ >>>>> . >>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presentin= g >>>>> remotely). I look forward for your comments! >>>>> >>>>> Here's just a bit of backstory, in case you are interested in how thi= s >>>>> doc came to be. The trajectory it followed is somewhat unusual. >>>>> >>>>> - Despite OAuth2 not requiring any specific format for ATs, >>>>> through the years I have come across multiple proprietary solution= using >>>>> JWT for their access token. The intent and scenarios addressed by = those >>>>> solutions are mostly the same across vendors, but the syntax and >>>>> interpretations in the implementations are different enough to pre= vent >>>>> developers from reusing code and skills when moving from product t= o product. >>>>> - I asked several individuals from key products and services to >>>>> share with me concrete examples of their JWT access tokens (THANK = YOU >>>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens a= nd >>>>> explanations!). >>>>> I studied and compared all those instances, identifying >>>>> commonalities and differences. >>>>> - I put together a presentation summarizing my findings and >>>>> suggesting a rough interoperable profile (slides: >>>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci= _-_a_jwt_profile_for_ats.pptx >>>>> >>>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>>> - The presentation was followed up by 1.5 hours of unconference >>>>> discussion, which was incredibly valuable to get tight-loop feedba= ck and >>>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuv= inov, >>>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all >>>>> there and contributed generously to the discussion. Thank you!!! >>>>> Note: if you were at OSW2019, participated in the discussion and >>>>> didn't get credited in the draft, my apologies: please send me a n= ote and >>>>> I'll make things right at the next update. >>>>> - On my flight back I did my best to incorporate all the ideas and >>>>> feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, >>>>> Hannes and above all Brian were all super helpful in negotiating t= he >>>>> mysterious syntax of the RFC format and submission process. >>>>> >>>>> I was blown away by the availability, involvement and willingness to >>>>> invest time to get things right that everyone demonstrated in the pro= cess. >>>>> This is an amazing community. >>>>> V. >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> >>>> -- >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Rob Otto EMEA Field CTO - Ping Identity +44 777 135 6092 --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000a383b70584fb4329 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I=E2=80=99d like to add my support for not proposing= any change to how sub is typically interpreted for client credentials toke= ns.=C2=A0 In my experience the usage of the client_id as the subject in thi= s flow is well established and it would cause disruption to many current im= plementations should that be changed =C2=A0
    Best regards
    Rob


    On Tue, 26 Mar 2019 at 08:27, Dave Tonge <dave.tonge@momentumft.co.uk>= wrote:
    Thanks Vittorio for your presentation and putting this draft toget= her.

    I agree with Dominck that there is a potential of thing= s going wrong when `sub` has multiple meanings.
    However I can see that= using `sub` for a client_id semantically makes sense in some situations an= d I agree that it makes it simpler from an SDK point of view for there to a= lways be a `sub`.

    My suggestion would be that either there i= s an explicit type to differentiate between "user access tokens" = and "application access tokens", or failing that the `sub` is use= d to indicate the difference.

    Furthermore an agreement on th= e naming and description of these two types of access tokens would be helpf= ul more generally.

    Dave

    On Tue, 26 Mar 2019 at 07:25, D= ominick Baier <dbaier@leastprivilege.com> wrote:
    From an access token consumer (aka API) developer poin= t of view, I prefer this logic

    "If sub is present - client acts on behalf of a user, if n= ot - not."

    Any= thing more complicated has a potential of going wrong.


    On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Yeah, I=E2=80=99m concerning user & client ids collision.
    I haven=E2=80=99t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

    If you can enforce collision resistant IDs between user & client instances, it=E2=80=99ll works fine. I feel its overkill though.

    Sent from my iPhone

    On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

    Hey Nov, Dominick, Hans-
    thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
    The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

    The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

    Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
    Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

    Thanks
    V.=C2=A0


    On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
    I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

    Hans.

    On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

    All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

    In reality this leads to potential security problems - this spec has the potential to rectify the situation.

    Dominick

    On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

    Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
    "The "sub" (subject) claim identifies the princip= al that is the
    =C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are normally statements
    =C2=A0 =C2=A0about the subject.=C2=A0 The subject value MUST either be scoped to be
    =C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
    =C2=A0 =C2=A0The processing of this claim is generally application specific"

    which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

    Hans.
    On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    IMHO the sub claim should always refer to the user - and nothing else.

    OIDC says:

    "Subject - Identifier for the End-User at the Issuer."

    client_id should be used to identify clients.

    cheers
    Dominick

    On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Thanks for the good starting point of standardizing JWT-ized AT.

    One feedback.
    The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
    It requires those 2 types of identifiers to be unique each other in the IdP context.

    I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

    thanks

    nov
    On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
    Dear all,
    I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
    I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

    Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
    I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
    V.
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --

    <= /div>
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --
    Rob Otto
    EMEA Field CTO - Ping Identi= ty
    +44 777 135 6092

    <= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000a383b70584fb4329-- From nobody Tue Mar 26 01:40:36 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02641202E2 for ; Tue, 26 Mar 2019 01:40: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.20150623.gappssmtp.com 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 7Sm79w3gI63l for ; Tue, 26 Mar 2019 01:40:24 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C2812029B for ; Tue, 26 Mar 2019 01:40:19 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id e22so9262812oiy.0 for ; Tue, 26 Mar 2019 01:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SIMvKCSSBv0VaxCb7Ce3m0/++3ZmUvDRPwTgcapn918=; b=B8gYbIMjPe/tidmwCKzEJIwTAlTNgkcV/0yeAFf2jBh+j4jNuzc+Qwbz9qRoDu4OsM zsqJKo7yj1sE32FQ3r+6T48ufDFRvVXK+rIfYWb5oMJTNzAWsWige7rpHy1nfNE3I54R GUpM5XWDkbxvkhrf4pGAxQQHQrB8Pq/bHoPBOSNOOfKplY2HOsFdgNoTiBUUHKnGe7qG 1QwtptkILamWndRkiY9syoFZXY9I/QpZ2uVs2wYRqu66BZjAEI0H5QQo5HF9hfVoy0C8 oQEaHj6aSSzj8PduI7wx+7Wt/Sb5LSE9rfmZd2nyHzkNOgB8YOoyiOzfjvliHyJ2PLKu k2EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SIMvKCSSBv0VaxCb7Ce3m0/++3ZmUvDRPwTgcapn918=; b=XkX4aa5EGHygmr0Aiz+nTWxvDV8TwV+QEWDAB0U3oFdlY7iTI2fzcys9MaI6oyTpuy +GHCXJGp7LE9Yde68/BWBr7hAjPsN6o6qqvkSHBujSseeZR6S6JlVPapo1ynAjiYTJ9p aD3W5niXVA9hjpEPPpaSTf26AMi9rdtnwy1gtS8uQiFRnsI9Nwi/sjR+V5jfRD43AoHy gU+/g8OlqUYyjfdnXcj/1q/geZPUMB1KQ14VJ5YxM3hHhKfi7Z8D5p7PEqAZZeW4PPnZ 6Lvg1e67kTtcbSbxDq/ziH/9g9ev/gkpHuEz/h3lUrSZD6xt25uqlv6WWBL6lDtYywK0 9mwA== X-Gm-Message-State: APjAAAUy0dCSqwbXnDxkoTBaoDyTjFG5QQ9KBsQQF0uKicVx1BAe7YlP AwdGaojBCXL7qjitvEHTZy/fAiI9u6a4QQjuCCGSbw== X-Google-Smtp-Source: APXvYqx3seRrkWJp6/ZOUReacbRBdkZRcQ08+AtYPGE94ZXxTSyDVsf7vMwDf8XENxLkaEFmsBPS0slOKfYt5S4CTO0= X-Received: by 2002:aca:5f03:: with SMTP id t3mr14546517oib.113.1553589618564; Tue, 26 Mar 2019 01:40:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Steinar Noem Date: Tue, 26 Mar 2019 09:40:04 +0100 Message-ID: To: Vittorio Bertocci , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000057772d0584fb45f0" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 08:40:34 -0000 --00000000000057772d0584fb45f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vittorio, we (the national federation-gateway for the health services in norway - "HelseID") think his is a really valuable initiative! We also agree with Dominick concerning definition of the "sub" claim. Steinar tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier : > From an access token consumer (aka API) developer point of view, I prefer > this logic > > "If sub is present - client acts on behalf of a user, if not - not." > > Anything more complicated has a potential of going wrong. > > > On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: > > Hi Vittorio, > > Yeah, I=E2=80=99m concerning user & client ids collision. > I haven=E2=80=99t seen such implementations, but user-select username as = sub, or > incremental integer as sub & client_id will be easily collide. > > If you can enforce collision resistant IDs between user & client > instances, it=E2=80=99ll works fine. I feel its overkill though. > > Sent from my iPhone > > On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote: > > Hey Nov, Dominick, Hans- > thanks for the comments. That was an area I was expecting to cause more > discussion, and I am glad we are having this opportunity to clarify. > The current language in the draft traces the etymology of sub to OpenID > Connect core, hence Dominick observation is on point. However in the > description I express something in line with 7519, which was in fact my > intent. > > The idea was to provide an identifier of the calling subject that is > guaranteed to be present in all cases- this would allow an SDK developer = to > use the same code for things like lookups and membership checks regardles= s > of the nature of the caller (user in a delegated case, app in app-only > grants). The information to discriminate between user and app callers is > always available in the token (say, the caller is a user if sub!=3Dclient= _id, > where client_id is always guaranteed to be present as well) hence there's > no loss in expressive power, should that difference be relevant for the > resource server. > > Dominick, Hans- I probably missed the security issue you guys are thinkin= g > of in this case. Of course, if this would introduce a risk I completely > agree it should be changed- I'd just like to understand better the proble= m. > Could you expand it in a scenario/use case to clarify the risk? > Nov- playing this back: is the concern that a user and a client might hav= e > the same identifier within an IDP? When using collision resistant IDs, as > it is usually the case, that seems to be a remote possibility- did you > stumble in such scenario in production? > > Thanks > V. > > > On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt > wrote: > >> I believe there are plenty of OAuth 2.0 only use cases out there... but >> nevertheless I agree with the potential confusion and thus security >> problems arising from that (though one may argue the semantics are the >> same). >> >> Hans. >> >> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier >> wrote: >> >>> Yes I know - and I think in hindsight it was a mistake to use the same >>> claim type for multiple semantics. >>> >>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making t= hings more >>> complicated than they need to be - in my experience almost no-one (that= I >>> know) does OIDC only - nor OAuth only. They always combine it. >>> >>> In reality this leads to potential security problems - this spec has th= e >>> potential to rectify the situation. >>> >>> Dominick >>> >>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.e= u) >>> wrote: >>> >>> Without agreeing or disagreeing: OIDC does not apply here since it is >>> not OAuth and an access token is not an id_token. >>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: >>> >>> "The "sub" (subject) claim identifies the principal that is the >>> subject of the JWT. The claims in a JWT are normally statements >>> about the subject. The subject value MUST either be scoped to be >>> locally unique in the context of the issuer or be globally unique. >>> The processing of this claim is generally application specific" >>> >>> which kind of spells "client" in case of the client credentials grant >>> but I also do worry about Resource Servers thinking/acting only in term= s of >>> users >>> >>> Hans. >>> >>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>> dbaier@leastprivilege.com> wrote: >>> >>>> IMHO the sub claim should always refer to the user - and nothing else. >>>> >>>> OIDC says: >>>> >>>> "Subject - Identifier for the End-User at the Issuer." >>>> >>>> client_id should be used to identify clients. >>>> >>>> cheers >>>> Dominick >>>> >>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>>> >>>> Hi Vittorio, >>>> >>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>> >>>> One feedback. >>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, end= -user and client, >>>> in this spec. >>>> It requires those 2 types of identifiers to be unique each other in th= e >>>> IdP context. >>>> >>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so = that no such >>>> constraint needed. >>>> >>>> thanks >>>> >>>> nov >>>> >>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>>> >>>> Dear all, >>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>>> tokens. You can find it in >>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt= / >>>> . >>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>>> remotely). I look forward for your comments! >>>> >>>> Here's just a bit of backstory, in case you are interested in how this >>>> doc came to be. The trajectory it followed is somewhat unusual. >>>> >>>> - Despite OAuth2 not requiring any specific format for ATs, through >>>> the years I have come across multiple proprietary solution using JW= T for >>>> their access token. The intent and scenarios addressed by those sol= utions >>>> are mostly the same across vendors, but the syntax and interpretati= ons in >>>> the implementations are different enough to prevent developers from= reusing >>>> code and skills when moving from product to product. >>>> - I asked several individuals from key products and services to >>>> share with me concrete examples of their JWT access tokens (THANK Y= OU >>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens an= d >>>> explanations!). >>>> I studied and compared all those instances, identifying >>>> commonalities and differences. >>>> - I put together a presentation summarizing my findings and >>>> suggesting a rough interoperable profile (slides: >>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_= -_a_jwt_profile_for_ats.pptx >>>> >>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>> - The presentation was followed up by 1.5 hours of unconference >>>> discussion, which was incredibly valuable to get tight-loop feedbac= k and >>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvi= nov, >>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>>> and contributed generously to the discussion. Thank you!!! >>>> Note: if you were at OSW2019, participated in the discussion and >>>> didn't get credited in the draft, my apologies: please send me a no= te and >>>> I'll make things right at the next update. >>>> - On my flight back I did my best to incorporate all the ideas and >>>> feedback in a draft, which will be discussed at IETF104 tomorrow. R= ifaat, >>>> Hannes and above all Brian were all super helpful in negotiating th= e >>>> mysterious syntax of the RFC format and submission process. >>>> >>>> I was blown away by the availability, involvement and willingness to >>>> invest time to get things right that everyone demonstrated in the proc= ess. >>>> This is an amazing community. >>>> V. >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >>> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --00000000000057772d0584fb45f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Vittorio, we=C2=A0 (the national federation-gateway for the health services in norway - "= HelseID")=C2=A0 think his is a really valuable initiative!
    We also= agree with Dominick concerning definition of the "sub" claim.

    <mvh>Steinar</mvh>

    tir. 26. mar. 20= 19 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com>:
    From an access token consumer (aka API) developer point of v= iew, I prefer this logic

    "If sub is present - client acts on behalf of a user, if not - n= ot."
    Anything = more complicated has a potential of going wrong.


    On 26. March 2019 at 01:34:53, Nov Matake (= matake@gmail.com)= wrote:

    Hi Vittorio,

    Yeah, I=E2=80=99m concerning user & client ids collision.
    I haven=E2=80=99t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

    If you can enforce collision resistant IDs between user & client instances, it=E2=80=99ll works fine. I feel its overkill though.

    Sent= from my iPhone

    On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

    Hey Nov, Dominick, Hans-
    thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
    The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

    The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

    Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
    Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

    Thanks
    V.=C2=A0


    On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
    I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

    Hans.

    On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

    All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

    In reality this leads to potential security problems - this spec has the potential to rectify the situation.

    Dominick

    On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

    Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
    "The "sub" (subject) claim identifies the princip= al that is the
    =C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are normally statements
    =C2=A0 =C2=A0about the subject.=C2=A0 The subject value MUST either be scoped to be
    =C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
    =C2=A0 =C2=A0The processing of this claim is generally application specific"

    which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

    Hans.
    On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    IMHO the sub claim should always refer to the user - and nothing else.

    OIDC says:

    "Subject - Identifier for the End-User at the Issuer."

    client_id should be used to identify clients.

    cheers
    Dominick

    On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Thanks for the good starting point of standardizing JWT-ized AT.

    One feedback.
    The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
    It requires those 2 types of identifiers to be unique each other in the IdP context.

    I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

    thanks

    nov
    On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
    Dear all,
    I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
    I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

    Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
    I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
    V.
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --


    --
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --
    Vennlig hilsen=

    Steinar Noem
    Partner Udelt AS
    Systemutvikler<= /div>
    =C2=A0
    |=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n= o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.= no=C2=A0|=C2=A0
    --00000000000057772d0584fb45f0-- From nobody Tue Mar 26 03:10:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60451202A1 for ; Tue, 26 Mar 2019 03:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com 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 WTQKu3ZoIUBB for ; Tue, 26 Mar 2019 03:10:50 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C72120282 for ; Tue, 26 Mar 2019 03:10:49 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id q1so13609317wrp.0 for ; Tue, 26 Mar 2019 03:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=/ClYNwn40FqYvSb53SKo2itSskz8mg8UQLJo1utHtpo=; b=D2u7bOfAAnE6bQhsg8BxyCTizcbD4pI6QfZpqaVhGLmdk2ijDbm6yu4JImNg64cnti 1uGiDjXksKfoTdfi8lm1tp3bTKKED9vDkOaDfafu85H1MzCrHpfOiLpje/mcqXn5e9nc xuEZZf+4wBkKB+4wx3hl5zs6ept2Z02/3kL4g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=/ClYNwn40FqYvSb53SKo2itSskz8mg8UQLJo1utHtpo=; b=S7rGlVGoKA6QjlxkvsW7tng30jSMf+dPV5seBGq0LKW9EDoRedJeyNn2KQd1hZFkIX hq+I4GnMIuL9+knrR19EBp6D0KNwe4/DGvR8gMUl8bVnogf+OJGhbd/SM8kluox4OjC0 /oNGWoYExWb5ocM4xOkDtIlZXgrTrwAHDjrJjc//+zbft5EmSgsiDvdaH5qoJna8iKbV MUCjswxQ0pq/xUkMwdFQVoQI19cmPIS2ulP46Vzh5m5YJN7e5hbO1gvMsMwBAxP55yOe +TqXZII2bUVSuFzv0CEpfOyXF3ieUef7AZrCDWWDSlxpypQSC1j2KqyhiQGG+NLYhuB+ 875Q== X-Gm-Message-State: APjAAAUUzqdao19oIKeiNGt4pEOWKtH8AswyoQV6Cs8+WEmWBw1QolmK mtsWcmxHkhGKXY/K0f2aWdc7Et8GhKbRt2YOVXI6mXwLYMwr9bmGUWFk/ed7zQQFXYSwVd3DQNx eTBX8Wxa8l9BRdrGFi8Jy2lJUwbszJcU9GgVuC6y5fIZduZkOwGkpfszzS7HDxBY= X-Google-Smtp-Source: APXvYqyzQMi+SPruBzBwTme+q5ZsWG/pnwlKtHiTAFOolUBnadfoksu0T0gJNdmndu8/yrnJNtWiig== X-Received: by 2002:adf:e60d:: with SMTP id p13mr18097108wrm.265.1553595047552; Tue, 26 Mar 2019 03:10:47 -0700 (PDT) Received: from guest2s-mbp.home.gateway (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id x192sm19877881wmf.48.2019.03.26.03.10.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 03:10:46 -0700 (PDT) From: Neil Madden Content-Type: multipart/alternative; boundary="Apple-Mail=_B07661EC-C4BE-446B-BD4F-FE3C729BE69F" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Tue, 26 Mar 2019 10:10:45 +0000 To: IETF oauth WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [OAUTH-WG] JWT ATs and authenticated encryption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 10:10:53 -0000 --Apple-Mail=_B07661EC-C4BE-446B-BD4F-FE3C729BE69F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There was a brief discussion at OSW about signing vs encryption for = JWT-based access tokens. I think it was Brian Campbell that pointed out = that you often want authenticated encryption rather than signing, and I = agree with this. Currently JOSE only supports authenticated encryption for symmetric = cryptography, which means that the AS and RS must agree a shared secret = key beforehand. (Or else the RS uses the token introspection endpoint = and doesn=E2=80=99t decrypt the token itself). Symmetric cryptography is = less than ideal when the AS and RS are in separate trust boundaries = (e.g., different companies). There are actually ways to do *public key* authenticated encryption, but = JOSE doesn=E2=80=99t support them yet. I wrote a 3-part blog series = about this recently [1], but I=E2=80=99ll summarise the tl;dr version = here. I think for JWT-based access tokens that contain identity = assertions, this is probably what you want in most cases as it provides = both confidentiality and authenticity without needing a bulky nested = signed-then-encrypted JWT. Is this something people would be interested = in, if I propose a draft? Details: The basic idea is to introduce one or more variants on ECDH-ES that = provide sender authentication. The most straightforward is to use = ECDH-SS =E2=80=94 i.e., Diffie-Hellman between two static key pairs, one = for the sender and one for the recipient, with no ephemeral keys. This = provides authenticated encryption so long as the content encryption = method is authenticated (which they all are in JOSE). But it has a = number of security downsides, which I describe in more detail in the = blog. (It might be useful in some IoT scenarios though). The better variant is to instead do ECDH-ESSS. That is, we generate a = random ephemeral key pair and do an agreement with the recipient=E2=80=99s= static public key, just like in ECDH-ES, but then we do another key = agreement between the sender=E2=80=99s static private key and the = recipient=E2=80=99s static private key. We then concatenate the two = shared secrets and feed them into ConcatKDF just like you would for = ECDH-ES. This is what NIST SP.800-56A [2] calls the =E2=80=9Cone-pass = unified model=E2=80=9D (section 6.2.1.2). If you squint a bit then it is = also very similar to the =E2=80=9CK=E2=80=9D one-way pattern in the = Noise protocol framework [3]. To spell it out, the process for encrypting a JWE with this new scheme = is as follows: Sender has long-term =E2=80=9Cstatic=E2=80=9D key pair: ssk,_spk (ssk =3D = sender secret key, etc) Recipient has long-term static key pair: rsk, rpk 1. Sender generates a random ephemeral key pair: esk, epk 2. Calculate Ze :=3D ecdh(esk, rpk) =E2=80=94 just like in ECDH-ES 3. Calculate Zs :=3D ecdh(ssk, rpk) 4. Let Z =3D Ze || Zs where || is concatenation 5. Run Z through ConcatKDF with PartyUInfo/PartyVInfo just as in ECDH-ES 6. Encrypt the message using the chosen =E2=80=9Cenc=E2=80=9D encryption = method using the key derived in step 5. On its own ECDH-ESSS has some decent security properties (including = authenticated encryption), but it is especially good when you want to = exchange lots of messages with the recipient. If the recipient replies = to your initial message using ECDH-ESSS but using the ephemeral public = key you sent in the first message as if it was your static public key, = then what you get is an interactive handshake very similar to the Noise = KK pattern [4] (squinting quite hard at this point). Both parties can = then use the derived key from step 5 of the second message as a shared = session key and send =E2=80=9Cdirect=E2=80=9D encrypted JWEs to each = other from that point on. This provides very strong security properties = listed later in the Noise spec, including forward secrecy and both = sender and recipient authentication with resistance to key compromise = impersonation. So beyond its usefulness for Access Token JWTs, this = scheme is a really versatile building block that you can use for lots of = advanced use-cases (e.g., PoP schemes). There are even nice formal models of the Noise handshake patterns in = ProVerif [5], but I think they are only valid for the specific details = of how Noise performs key derivation and transcript hashing so they = wouldn=E2=80=99t directly apply to a JOSE version. [1] = https://neilmadden.blog/2018/11/14/public-key-authenticated-encryption-and= -why-you-want-it-part-i/ = [2] = https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pd= f = [3] https://noiseprotocol.org/noise.html#one-way-handshake-patterns = =20 [4] = https://noiseprotocol.org/noise.html#interactive-handshake-patterns-fundam= ental = =20 [5] https://noiseexplorer.com Cheers, Neil= --Apple-Mail=_B07661EC-C4BE-446B-BD4F-FE3C729BE69F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    There was a brief discussion at = OSW about signing vs encryption for JWT-based access tokens. I think it = was Brian Campbell that pointed out that you often want authenticated = encryption rather than signing, and I agree with this.

    Currently JOSE only supports authenticated encryption for = symmetric cryptography, which means that the AS and RS must agree a = shared secret key beforehand. (Or else the RS uses the token = introspection endpoint and doesn=E2=80=99t decrypt the token itself). = Symmetric cryptography is less than ideal when the AS and RS are in = separate trust boundaries (e.g., different companies).

    There are actually ways = to do *public key* authenticated encryption, but JOSE doesn=E2=80=99t = support them yet. I wrote a 3-part blog series about this recently [1], = but I=E2=80=99ll summarise the tl;dr version here. I think for JWT-based = access tokens that contain identity assertions, this is probably what = you want in most cases as it provides both confidentiality and = authenticity without needing a bulky nested signed-then-encrypted JWT. = Is this something people would be interested in, if I propose a = draft?

    Details:

    The basic idea is to introduce one or more variants on = ECDH-ES that provide sender authentication. The most straightforward is = to use ECDH-SS =E2=80=94 i.e., Diffie-Hellman between two static key = pairs, one for the sender and one for the recipient, with no ephemeral = keys. This provides authenticated encryption so long as the content = encryption method is authenticated (which they all are in JOSE). But it = has a number of security downsides, which I describe in more detail in = the blog. (It might be useful in some IoT scenarios though).

    The better variant is to = instead do ECDH-ESSS. That is, we generate a random ephemeral key pair = and do an agreement with the recipient=E2=80=99s static public key, just = like in ECDH-ES, but then we do another key agreement between the = sender=E2=80=99s static private key and the recipient=E2=80=99s static = private key. We then concatenate the two shared secrets and feed them = into ConcatKDF just like you would for ECDH-ES. This is what NIST = SP.800-56A [2] calls the =E2=80=9Cone-pass unified model=E2=80=9D = (section 6.2.1.2). If you squint a bit then it is also very similar to = the =E2=80=9CK=E2=80=9D one-way pattern in the Noise protocol framework = [3].

    To spell = it out, the process for encrypting a JWE with this new scheme is as = follows:

    Sender = has long-term =E2=80=9Cstatic=E2=80=9D key pair: ssk,_spk (ssk =3D = sender secret key, etc)
    Recipient has long-term = static key pair: rsk, rpk

    1. Sender generates a random ephemeral key pair: esk, = epk
    2. Calculate Ze :=3D ecdh(esk, rpk)  =E2=80=94= just like in ECDH-ES
    3. Calculate Zs :=3D = ecdh(ssk, rpk)
    4. Let Z =3D Ze || Zs where || is = concatenation
    5. Run Z through ConcatKDF with = PartyUInfo/PartyVInfo just as in ECDH-ES
    6. Encrypt = the message using the chosen =E2=80=9Cenc=E2=80=9D encryption method = using the key derived in step 5.

    On its own ECDH-ESSS has some decent = security properties (including authenticated encryption), but it is = especially good when you want to exchange lots of messages with the = recipient. If the recipient replies to your initial message using = ECDH-ESSS but using the ephemeral public key you sent in the first = message as if it was your static public key, then what you get is an = interactive handshake very similar to the Noise KK pattern [4] = (squinting quite hard at this point). Both parties can then use the = derived key from step 5 of the second message as a shared session key = and send =E2=80=9Cdirect=E2=80=9D encrypted JWEs to each other from that = point on. This provides very strong security properties listed later in = the Noise spec, including forward secrecy and both sender and recipient = authentication with resistance to key compromise impersonation. So = beyond its usefulness for Access Token JWTs, this scheme is a really = versatile building block that you can use for lots of advanced use-cases = (e.g., PoP schemes).

    There are even nice formal models of the Noise handshake = patterns in ProVerif [5], but I think they are only valid for the = specific details of how Noise performs key derivation and transcript = hashing so they wouldn=E2=80=99t directly apply to a JOSE = version.

    [1] https://neilmadden.blog/2018/11/14/public-key-authenticated-enc= ryption-and-why-you-want-it-part-i/
    [2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.8= 00-56Ar3.pdf
    [3] https://noiseprotocol.org/noise.html#one-way-handshake-patterns=  
    [4] https://noiseprotocol.org/noise.html#interactive-handshake-patt= erns-fundamental 
    [5] https://noiseexplorer.com

    Cheers,

    Neil
    = --Apple-Mail=_B07661EC-C4BE-446B-BD4F-FE3C729BE69F-- From nobody Tue Mar 26 07:35:58 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FA812034B for ; Tue, 26 Mar 2019 07:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 Guc3hBnmHWIC for ; Tue, 26 Mar 2019 07:35:51 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650102.outbound.protection.outlook.com [40.107.65.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CAC1202CC for ; Tue, 26 Mar 2019 07:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qffKmoRv95APwlvvbgR2JjdCX+gYgcJxVK0Wpz1oNJQ=; b=kZzYVoJoSrTmvQRS0mluGPZeTR5Na/JrVAIMasvUsE5M0bd2VJlcPS3oNVFYWosFh5RzkqS0sdhGmgHRbUnmcHwFwQb1NfT65oSpB4rrY/JrruE8bH8RNLMX/5Ecu9926dmAtWWOETvLNCbLLfM7FV7cy+BCg2KkR07izviwXpQ= ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=alJ6abdr6k4HtJdiJXqkpaAWo7A0Vd1boF2KhSzg7C21ge+ux7WSUZxTVWmF9+wj34I0o3ZFjAwaTKIvQ0AP++SK/FbQ6PHP8j5WjJPiEcw1e6qs+xDzfqgoBruFEB/cr2VHHGxhTVGQlni8JurTNBmorKb6+59U3S6jlHyrq1A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qffKmoRv95APwlvvbgR2JjdCX+gYgcJxVK0Wpz1oNJQ=; b=MwsJXNNwxHBnt63fHaO8prPOWxHi+Fdko6ifwHNK1KqrFKiKFA6CKb9fK5BYWrcJ6f8TwpprexnzwkcxtfX9tHPNp3/PQEaJB9LjN+UMAo+aebxvy3wdiqs/qLUjWL3QfjcFdc2tDClUuBhKpexDSNYOvZ00C+nlOJpc+IWqFp4= ARC-Authentication-Results: i=1; test.office365.com 1;dmarc=none action=none header.from=microsoft.com;arc=none Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0307.namprd00.prod.outlook.com (52.132.19.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1784.0; Tue, 26 Mar 2019 14:35:47 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::7487:5435:65d8:f2a8]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::7487:5435:65d8:f2a8%4]) with mapi id 15.20.1786.000; Tue, 26 Mar 2019 14:35:47 +0000 From: Mike Jones To: "oauth@ietf.org" CC: Pamela Dingle Thread-Topic: Review of draft-ietf-oauth-signed-http-request-03 Thread-Index: AdTj4F/QzsPC6xfER+SScmX5Gzzt4g== Date: Tue, 26 Mar 2019 14:35:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.168.35.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dc91cac3-5a11-46fd-fbaf-08d6b1f85665 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BL0PR00MB0307; x-ms-traffictypediagnostic: BL0PR00MB0307: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(346002)(366004)(376002)(39860400002)(199004)(189003)(14454004)(2906002)(10090500001)(26005)(6116002)(102836004)(6346003)(2351001)(86362001)(478600001)(86612001)(72206003)(6506007)(186003)(790700001)(316002)(3846002)(105586002)(22452003)(10290500003)(966005)(106356001)(2501003)(97736004)(606006)(8990500004)(5640700003)(7736002)(71190400001)(236005)(55016002)(74316002)(9686003)(54896002)(8936002)(81156014)(1730700003)(8676002)(6916009)(256004)(25786009)(107886003)(4326008)(33656002)(53936002)(6436002)(66066001)(52536014)(486006)(7696005)(5660300002)(68736007)(81166006)(476003)(71200400001)(99286004)(14444005)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0307; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 87g/ll/tnBbrdouSi7DQMdsRrVZoaB9ciXJuAhHAGasDx/XZVI4yBdhkYmnnIU/wu5iDLJ2T9ImKTCOy7M3ziHKH1MUlc9J6jx71rPupGuZ46KunOXA8JsGkX/rTdZCOKVTaFy3yPVARqhXbjL+4V+s6H/m4+OV19wqdg6T1wjS1o/PfFPjXI+93MpthV5P8qmy/jPRTUsShTpVKSvrany+JVlH/RbNd0K2oXPqHAVUBK70SDxbyJHcns7RcLLfFEdJuNsAIQpHln7iRdN/giNuwJvp9mEfEKQzhPZxe0SbHUrDohKlKHnMtot2/wHWRDu22lXNGxeBh3+6vkdczheAM/e97GFZQsh4TcsYXvxyxcVdIjTNYqL3/BCkHEEHumUTChWrlWQEvCww8y6KGYzU0VBwPfZnNgPfi3O48ukc= Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292AD1AE85165772A28E8FDF55F0BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: dc91cac3-5a11-46fd-fbaf-08d6b1f85665 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 14:35:47.6595 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0307 Archived-At: Subject: [OAUTH-WG] Review of draft-ietf-oauth-signed-http-request-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 14:35:57 -0000 --_000_BL0PR00MB0292AD1AE85165772A28E8FDF55F0BL0PR00MB0292namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are some deployments that I'm aware of that are considering using dra= ft-ietf-oauth-signed-http-request. Because of that, I've done a detailed r= eview of https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-0= 3, which follows. Only substantive issues are discussed. If the draft is = checked into GitHub, I'd be glad to create a pull request for a set of acco= mpanying editorial suggestions. If it isn't, I can send the editorial sugg= estions in a subsequent message. SUBSTANTIVE ISSUES 1. Introduction - The draft says "it is desirable to bind the signature to = the HTTP request". It would be great to say why this is desirable and what= attributes one might want to have bound. (The "what attributes" discussio= n could go in the Security Considerations section, as requested below.) 3. Generating a JSON Object from an HTTP Request - Why is "at" required? = The spec would be far more general if this field was OPTIONAL like the othe= rs. Is there any reason not to do this, while still staying that it's requ= ired in the PoP-protected access token use case? 3. "ts" parameter - State that this value is a NumericDate as defined in R= FC 7519. (That way you'll inherit the POSIX.1 language about leap seconds,= etc.) 3. "Note to WG" - I suspect that this wouldn't get past the IESG without c= rypto agility. A parameter probably needs to be introduced to specify the = hash algorithm used - with the default being SHA-256 if omitted. 3.1. Calculating the query parameter list and hash - The draft says that "= The client iterates through all query parameters in whatever order it choos= es...". I suspect this would be a lot less error prone if instead, it was = specified that the query parameters are to be processed in the order that t= hey will appear in the query string. 3.2. Bullet 3: At a minimum, this clause needs to describe what the canon= ical encoding is if an input value is preceded by or followed by space or t= ab characters. Are those stripped before being used in the "name: value" c= onstruct? 3.2. Bullet 3: Is a newline terminator present for all "name: value" line= s or is it only used between lines, with there being none at the end of the= value to be encoded? This should be explicitly stated. 4.2. HTTP Form Body - The draft defines the name "pop_access_token", which= seems like a misnomer, because the PoP access token is actually passed in = the "at" parameter as part of this value. I would suggest renaming this to= either "pop_http_message" or "signed_http_message". 4.3. HTTP Query Parameter - Ditto to my naming comment in 4.2. 6.2. "typ":"pop" registration - The draft doesn't say when this type can o= r must be used. For instance, is this intended to be used in the access to= ken representation the case where the PoP access token is represented as a = JWT? Or is it intended to be used for the signed HTTP message JWT header? = Or both? And is its use optional or required in which cases? 7. Security Considerations, Guidance to Applications - The draft provides = almost no guidance to application designers about which parameters should b= e signed and when. For instance, I'd think that many applications would wa= nt to sign URL components (the "u", "p", and "q" parameters). If so, pleas= e provide guidance on when these should be included. Likewise, if there's = a set of headers that one would normally expect to include in the signature= , please name them and provide justification for their inclusion. Finally,= if there are headers that one should normally *not* include, please also l= ist those and say why. Left to their own devices, application designers ar= e almost certain to choose many distinct and sub-optional sets of choices. 7.5. Validating the integrity of the HTTP message - The third paragraph sa= ys that "If a header or query parameter is repeated on either the outgoing = request from the client or the incoming request to the protected resource, = that query parameter or header name MUST NOT be covered by the hash and sig= nature." This doesn't seem to be consistent with the creation and validati= on procedures described earlier in the draft, which essentially said that p= arameters are processed in the chosen order and appended to the arrays. It= 's perfectly meaningful to have multiple instances of some parameters and s= o it's counterproductive to prohibit them being signed. Please remove this= prohibition (and if you like, replace it with a warning that order must be= preserved for the signature to validate - which is true of all parameters = - not just parameters that occur multiple times). Thanks, -- Mike P.S. Yes, I realize that some other PoP options are also in the works base= d on discussions at the OAuth Security Workshop. But I wanted to get these= issues on record for those who are considering using the existing signed-h= ttp-request draft. --_000_BL0PR00MB0292AD1AE85165772A28E8FDF55F0BL0PR00MB0292namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    There are some deployments that I’m aware of t= hat are considering using draft-ietf-oauth-signed-http-request.  Becau= se of that, I’ve done a detailed review of https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03, which follows.  Only substantive issues are discussed.  If the= draft is checked into GitHub, I’d be glad to create a pull request for a set of accompanying editorial suggestions.&nbs= p; If it isn’t, I can send the editorial suggestions in a subsequent = message.

     

    SUBSTANTIVE ISSUES

     

    1. Introduction – The draft says “it is = desirable to bind the signature to the HTTP request”.  It would = be great to say why this is desirable and what attributes one might want to= have bound.  (The “what attributes” discussion could go in the Security Considerations section, as requested below.)

     

    3.  Generating a JSON Object from an HTTP Reque= st – Why is “at” required?  The spec would be far mo= re general if this field was OPTIONAL like the others.  Is there any r= eason not to do this, while still staying that it’s required in the PoP-protected access token use case?

     

    3.  “ts” parameter – State th= at this value is a NumericDate as defined in RFC 7519.  (That way you&= #8217;ll inherit the POSIX.1 language about leap seconds, etc.)<= /p>

     

    3.  “Note to WG” – I suspect = that this wouldn’t get past the IESG without crypto agility.  A = parameter probably needs to be introduced to specify the hash algorithm use= d – with the default being SHA-256 if omitted.

     

    3.1.  Calculating the query parameter list and = hash – The draft says that “The client iterates through all que= ry parameters in whatever order it chooses…”.  I suspect t= his would be a lot less error prone if instead, it was specified that the query parameters are to be processed in the order that they will appea= r in the query string.

     

    3.2.  Bullet 3:  At a minimum, this clause= needs to describe what the canonical encoding is if an input value is prec= eded by or followed by space or tab characters.  Are those stripped be= fore being used in the “name: value” construct?

     

    3.2.  Bullet 3:  Is a newline terminator p= resent for all “name: value” lines or is it only used between l= ines, with there being none at the end of the value to be encoded?  Th= is should be explicitly stated.

     

    4.2.  HTTP Form Body – The draft defines = the name “pop_access_token”, which seems like a misnomer, becau= se the PoP access token is actually passed in the “at” paramete= r as part of this value.  I would suggest renaming this to either R= 20;pop_http_message” or “signed_http_message”.

     

    4.3.  HTTP Query Parameter – Ditto to my = naming comment in 4.2.

     

    6.2.  “typ”:”pop” regis= tration – The draft doesn’t say when this type can or must be u= sed.  For instance, is this intended to be used in the access token re= presentation the case where the PoP access token is represented as a JWT?&n= bsp; Or is it intended to be used for the signed HTTP message JWT header?  Or bo= th?  And is its use optional or required in which cases?

     

    7.  Security Considerations, Guidance to Applic= ations – The draft provides almost no guidance to application designe= rs about which parameters should be signed and when.  For instance, I&= #8217;d think that many applications would want to sign URL components (the “u”, “p”, and “q” = parameters).  If so, please provide guidance on when these should be i= ncluded.  Likewise, if there’s a set of headers that one would n= ormally expect to include in the signature, please name them and provide ju= stification for their inclusion.  Finally, if there are headers that one should n= ormally *not* include, please also list those and say why.  Left to th= eir own devices, application designers are almost certain to choose many di= stinct and sub-optional sets of choices.

     

    7.5.  Validating the integrity of the HTTP mess= age – The third paragraph says that “If a header or query param= eter is repeated on either the outgoing request from the client or the inco= ming request to the protected resource, that query parameter or header name MUST NOT be covered by the hash and signature.= 221;  This doesn’t seem to be consistent with the creation and v= alidation procedures described earlier in the draft, which essentially said= that parameters are processed in the chosen order and appended to the arrays.  It’s perfectly meaningful to have = multiple instances of some parameters and so it’s counterproductive t= o prohibit them being signed.  Please remove this prohibition (and if = you like, replace it with a warning that order must be preserved for the signature to validate – which is true of all param= eters – not just parameters that occur multiple times).

     

            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           Thanks,

            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           -- Mike

     

    P.S.  Yes, I realize that some other PoP option= s are also in the works based on discussions at the OAuth Security Workshop= .  But I wanted to get these issues on record for those who are consid= ering using the existing signed-http-request draft.

     

    --_000_BL0PR00MB0292AD1AE85165772A28E8FDF55F0BL0PR00MB0292namp_-- From nobody Tue Mar 26 09:48:28 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4639C1204C4 for ; Tue, 26 Mar 2019 09:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 oh4ETtR5UGZA for ; Tue, 26 Mar 2019 09:48:22 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6081205F8 for ; Tue, 26 Mar 2019 09:48:21 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id y6so11737260ljd.12 for ; Tue, 26 Mar 2019 09:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VQc6vO9/xfe+kYKhe1COoyLtRetyHRnHFnLQ4ercs7g=; b=kdPSKMqReXoGq1v+I6kresTFluWF9pJ4Wq3aedY7+myfBnMeRzOc0yMXdlEqSf6QFv r1G7zdFo08hp1Qpn1z/FYQ2Y7Rdl2SgRnlCE64y8b8r2zuorMM2DmHpNte5Z+txZewZ+ I+dj8GHLAvVTBMF3cC97riyAQQ2jYu2mOOQiVQbjY/lu6WLC8Ty88DPQEyubUSPMpU+B atgtoyC5iglLTg1I4RPdlb4l98Q0bD4w+2akBoEGn9E8h5PBifDzbiRubrQzMwFxGnmi xa0uT27zT2WVJZpeT2iS0SBHy0sUIANOH7PnxTLvvDZb2ZohSnsHb3RSoNHAueDdfZWD Tk+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VQc6vO9/xfe+kYKhe1COoyLtRetyHRnHFnLQ4ercs7g=; b=WBf623/ONtUy5ZfUP0hzWFsMmukm9n16pm3K1Dgv3swD8G3NBMOW12fZqBUBoE1kKy VGAhUbqVcy1VBjtETI+jnMF96G8TJPCu27Sph9h4N7XIas1l9qnP/sUaBqBkne0IlU9k uMQG0bKLllZUrTh3if6orX1OIHcZ1sHUoBjcC2KfGoTdxy4+nqd8qi03IcQ+6EBHUwO0 lM6Ncv22XeYAax+NLJ6cJpQjRUhUCgvxW4c+mKa9ZdrwmeltKZ/rJikzrdnSt1AAB1YF iK6iIrf2OGlHVpaU7JSWKgXvbMAXCD654kUhdiscofX8vssN34U4ms+ixgo0xkMyStkd egWw== X-Gm-Message-State: APjAAAXHIjv5HYNPGge+nn6CgUNYkczgpmpg9cRsMK2l/M5T6QulWJrI FI/2f8pp0xIxPwbCxsyTLRMF1HgIECrdFnzEaK9WlQ== X-Google-Smtp-Source: APXvYqxp8R/MOzVjvymzDykfHU4+FJVAb8PPx41Pn2ssDAItiIoB+CTgCx/6//cq8TSOe8d206IlHZmPxSShW4IMaxU= X-Received: by 2002:a2e:b1c7:: with SMTP id e7mr16592791lja.107.1553618899836; Tue, 26 Mar 2019 09:48:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vittorio Bertocci Date: Tue, 26 Mar 2019 09:48:08 -0700 Message-ID: To: Steinar Noem Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000a436c70585021670" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 16:48:27 -0000 --000000000000a436c70585021670 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable thank you Steinar and everyone else for the comments on this! To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin would like to have the sub for app only flows as well. Hans is neutral. That does sound like the sub as user has more consensus, tho before changing it I'd wait for the people currently at IETF104 to have more time to comment as well. Clarification. If the goal is to be able to apply the logic "if there's a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it? Dave, the suggestion of having explicit typing for app only vs user only is interesting! For the purpose of putting together an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence with small delta vs existing implementations) faster. On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote: > Hi Vittorio, we (the national federation-gateway for the health services > in norway - "HelseID") think his is a really valuable initiative! > We also agree with Dominick concerning definition of the "sub" claim. > > Steinar > > tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier < > dbaier@leastprivilege.com>: > >> From an access token consumer (aka API) developer point of view, I prefe= r >> this logic >> >> "If sub is present - client acts on behalf of a user, if not - not." >> >> Anything more complicated has a potential of going wrong. >> >> >> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >> >> Hi Vittorio, >> >> Yeah, I=E2=80=99m concerning user & client ids collision. >> I haven=E2=80=99t seen such implementations, but user-select username as= sub, or >> incremental integer as sub & client_id will be easily collide. >> >> If you can enforce collision resistant IDs between user & client >> instances, it=E2=80=99ll works fine. I feel its overkill though. >> >> Sent from my iPhone >> >> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote: >> >> Hey Nov, Dominick, Hans- >> thanks for the comments. That was an area I was expecting to cause more >> discussion, and I am glad we are having this opportunity to clarify. >> The current language in the draft traces the etymology of sub to OpenID >> Connect core, hence Dominick observation is on point. However in the >> description I express something in line with 7519, which was in fact my >> intent. >> >> The idea was to provide an identifier of the calling subject that is >> guaranteed to be present in all cases- this would allow an SDK developer= to >> use the same code for things like lookups and membership checks regardle= ss >> of the nature of the caller (user in a delegated case, app in app-only >> grants). The information to discriminate between user and app callers is >> always available in the token (say, the caller is a user if sub!=3Dclien= t_id, >> where client_id is always guaranteed to be present as well) hence there'= s >> no loss in expressive power, should that difference be relevant for the >> resource server. >> >> Dominick, Hans- I probably missed the security issue you guys are >> thinking of in this case. Of course, if this would introduce a risk I >> completely agree it should be changed- I'd just like to understand bette= r >> the problem. Could you expand it in a scenario/use case to clarify the r= isk? >> Nov- playing this back: is the concern that a user and a client might >> have the same identifier within an IDP? When using collision resistant I= Ds, >> as it is usually the case, that seems to be a remote possibility- did yo= u >> stumble in such scenario in production? >> >> Thanks >> V. >> >> >> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt >> wrote: >> >>> I believe there are plenty of OAuth 2.0 only use cases out there... but >>> nevertheless I agree with the potential confusion and thus security >>> problems arising from that (though one may argue the semantics are the >>> same). >>> >>> Hans. >>> >>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier < >>> dbaier@leastprivilege.com> wrote: >>> >>>> Yes I know - and I think in hindsight it was a mistake to use the same >>>> claim type for multiple semantics. >>>> >>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making = things more >>>> complicated than they need to be - in my experience almost no-one (tha= t I >>>> know) does OIDC only - nor OAuth only. They always combine it. >>>> >>>> In reality this leads to potential security problems - this spec has >>>> the potential to rectify the situation. >>>> >>>> Dominick >>>> >>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ( >>>> hans.zandbelt@zmartzone.eu) wrote: >>>> >>>> Without agreeing or disagreeing: OIDC does not apply here since it is >>>> not OAuth and an access token is not an id_token. >>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2= : >>>> >>>> "The "sub" (subject) claim identifies the principal that is the >>>> subject of the JWT. The claims in a JWT are normally statements >>>> about the subject. The subject value MUST either be scoped to be >>>> locally unique in the context of the issuer or be globally unique. >>>> The processing of this claim is generally application specific" >>>> >>>> which kind of spells "client" in case of the client credentials grant >>>> but I also do worry about Resource Servers thinking/acting only in ter= ms of >>>> users >>>> >>>> Hans. >>>> >>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>>> dbaier@leastprivilege.com> wrote: >>>> >>>>> IMHO the sub claim should always refer to the user - and nothing else= . >>>>> >>>>> OIDC says: >>>>> >>>>> "Subject - Identifier for the End-User at the Issuer." >>>>> >>>>> client_id should be used to identify clients. >>>>> >>>>> cheers >>>>> Dominick >>>>> >>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>>>> >>>>> Hi Vittorio, >>>>> >>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>> >>>>> One feedback. >>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, en= d-user and >>>>> client, in this spec. >>>>> It requires those 2 types of identifiers to be unique each other in >>>>> the IdP context. >>>>> >>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, so= that no such >>>>> constraint needed. >>>>> >>>>> thanks >>>>> >>>>> nov >>>>> >>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>>>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>>>> >>>>> Dear all, >>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 acces= s >>>>> tokens. You can find it in >>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jw= t/ >>>>> . >>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presentin= g >>>>> remotely). I look forward for your comments! >>>>> >>>>> Here's just a bit of backstory, in case you are interested in how thi= s >>>>> doc came to be. The trajectory it followed is somewhat unusual. >>>>> >>>>> - Despite OAuth2 not requiring any specific format for ATs, >>>>> through the years I have come across multiple proprietary solution= using >>>>> JWT for their access token. The intent and scenarios addressed by = those >>>>> solutions are mostly the same across vendors, but the syntax and >>>>> interpretations in the implementations are different enough to pre= vent >>>>> developers from reusing code and skills when moving from product t= o product. >>>>> - I asked several individuals from key products and services to >>>>> share with me concrete examples of their JWT access tokens (THANK = YOU >>>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens a= nd >>>>> explanations!). >>>>> I studied and compared all those instances, identifying >>>>> commonalities and differences. >>>>> - I put together a presentation summarizing my findings and >>>>> suggesting a rough interoperable profile (slides: >>>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci= _-_a_jwt_profile_for_ats.pptx >>>>> >>>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>>> - The presentation was followed up by 1.5 hours of unconference >>>>> discussion, which was incredibly valuable to get tight-loop feedba= ck and >>>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuv= inov, >>>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all >>>>> there and contributed generously to the discussion. Thank you!!! >>>>> Note: if you were at OSW2019, participated in the discussion and >>>>> didn't get credited in the draft, my apologies: please send me a n= ote and >>>>> I'll make things right at the next update. >>>>> - On my flight back I did my best to incorporate all the ideas and >>>>> feedback in a draft, which will be discussed at IETF104 tomorrow. = Rifaat, >>>>> Hannes and above all Brian were all super helpful in negotiating t= he >>>>> mysterious syntax of the RFC format and submission process. >>>>> >>>>> I was blown away by the availability, involvement and willingness to >>>>> invest time to get things right that everyone demonstrated in the pro= cess. >>>>> This is an amazing community. >>>>> V. >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> >>>> -- >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Vennlig hilsen > > Steinar Noem > Partner Udelt AS > Systemutvikler > > | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | > --000000000000a436c70585021670 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    thank you Steinar and everyone else for the comments on th= is!
    To summarize the situation so far: Dominick, Steinar, Rob, David, N= ov, Bertrand recommend using sub only for users. Martin would like to have = the sub for app only flows as well. Hans is neutral.
    That does so= und like the sub as user has more consensus, tho before changing it I'd= wait for the people currently at IETF104 to have more time to comment as w= ell.
    Clarification. If the goal is to be able to apply the logic = "if there's a sub, it's a user flow", we have to explicit= ly disallow (MUST NOT) the use of sub when that's not the case. Are all= OK with it?

    Dave, the suggestion of having explic= it typing for app only vs user only is interesting! For the purpose of putt= ing together an interoperable profile, tho, I would suggest we table it for= v1 in the interest of getting to something easy to adopt (hence with small= delta vs existing implementations) faster.=C2=A0 =C2=A0 =C2=A0
    =
    On Tue= , Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no> wrote:
    Hi Vittorio, we=C2=A0 (the national federation-gateway for the health services in norway - "= HelseID")=C2=A0 think his is a really valuable initiative!
    We also= agree with Dominick concerning definition of the "sub" claim.

    <mvh>Steinar</mvh>

    tir. 26. mar. 20= 19 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com>:
    From an access token consumer (aka API) de= veloper point of view, I prefer this logic

    "If sub is present - client acts on behalf of = a user, if not - not."

    Anything more complicated has a potential of going wrong.

    On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wr= ote:

    Hi Vittorio,

    Yeah, I=E2=80=99m concerning user & client ids collision.
    I haven=E2=80=99t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

    If you can enforce collision resistant IDs between user & client instances, it=E2=80=99ll works fine. I feel its overkill though.

    Sent from my iPhone

    On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

    Hey Nov, Dominick, Hans-
    thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
    The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

    The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

    Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
    Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

    Thanks
    V.=C2=A0


    On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
    I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

    Hans.

    On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

    All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

    In reality this leads to potential security problems - this spec has the potential to rectify the situation.

    Dominick

    On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

    Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
    "The "sub" (subject) claim identifies the princip= al that is the
    =C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are normally statements
    =C2=A0 =C2=A0about the subject.=C2=A0 The subject value MUST either be scoped to be
    =C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
    =C2=A0 =C2=A0The processing of this claim is generally application specific"

    which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

    Hans.
    On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    IMHO the sub claim should always refer to the user - and nothing else.

    OIDC says:

    "Subject - Identifier for the End-User at the Issuer."

    client_id should be used to identify clients.

    cheers
    Dominick

    On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Thanks for the good starting point of standardizing JWT-ized AT.

    One feedback.
    The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
    It requires those 2 types of identifiers to be unique each other in the IdP context.

    I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

    thanks

    nov
    On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
    Dear all,
    I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
    I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

    Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
    I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
    V.
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --


    --
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --
    Vennlig hilsen

    Steinar Noem
    Partner Udelt AS
    Systemutvikler
    =C2=A0
    |=C2=A0steinar@udelt.no=C2= =A0|=C2=A0hei@udelt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2= =A0|=C2=A0www.udelt.no=C2=A0|=C2=A0
    --000000000000a436c70585021670-- From nobody Tue Mar 26 09:50:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE49312063F for ; Tue, 26 Mar 2019 09:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 dCp0tNZRpAYZ for ; Tue, 26 Mar 2019 09:50:49 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9472412063D for ; Tue, 26 Mar 2019 09:50:48 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id u68so9212680lff.7 for ; Tue, 26 Mar 2019 09:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qz1YdAY0mzfxqxX+xbD95P6qXDcsnuMVw21AsV3n0Ho=; b=B+LWVMcbQ0GCbiLLnbCqJh1f2VNFxXMMPZ2qRQZn7RrNU7Xv3iImrOwjnrafP1VuBC +S8YZCr/iOJgfzSxp2yGJTFANa3uKdjaWZABq7yfkaZQVBD64J5tIhZw3esOwhbyk9aD EICnY/ZaONYRH6uhkiAJFNRR1EqyN1cfixTPH9W2i0CiI4XZoIbcMVg7QcA9VYGdevjg 4NGxn8e21nPhmweeOG3xOaQx9VT3iWkZVjf+YZycY/u1JjMiRUf5IRPMvrO7lvjw9gN1 CIqIJbB3MFOEXON9+JAZT8XoC/DNGPuUupiaRAszmIK/MULq5BmB/7JUMwzQlb2ojhZU oSDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qz1YdAY0mzfxqxX+xbD95P6qXDcsnuMVw21AsV3n0Ho=; b=pXUkQf2ilPDsHz2oVTY/J90ezvOcwkt1NSashomoBxI94xQUlRW2c+77aYR+dHabKP lBCC681QgPYlOhZ4Vjzo09p/Inuu8cTaZFoB7xLPxXgZ5VkItrj6MVbXczbmu/53nR+t 0F+pL6k/fJ7WapeN+hr53FrqEJA69lrbkHYI9HdmXoAt4//5BOcxYRfuz/rpoxriBM9U nfba60FL4rKItADI7/bYOyPwV77eVgszwD5oqv93K+GsZsL1P6zmlsHA67j9u+26KNpd LjAoyzy/G/kR/Ul1fUWhkxjqD7m9q344VUp8SUqhimPQ83JY0kLqR11rn37pJFJXN6tI arCQ== X-Gm-Message-State: APjAAAUuZOSe6R5hOBuromlJYSOFMyfC0nNtDJUQYrd+TcyHg+ZU+eUv c9X2Vss4lFMS+NMcrwzML2HevkOz6Et+W1dHfp5P5w== X-Google-Smtp-Source: APXvYqxb6LaKm+AtNRsvtEvdDsarhvAzN727YGaWi1Oszok0RrWyhwbQa4Osu86KinP11rUYonCotT5bIx6WOTJGFb0= X-Received: by 2002:a19:700c:: with SMTP id h12mr5321458lfc.78.1553619046585; Tue, 26 Mar 2019 09:50:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vittorio Bertocci Date: Tue, 26 Mar 2019 09:50:35 -0700 Message-ID: To: Neil Madden Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000006374f20585021f45" Archived-At: Subject: Re: [OAUTH-WG] JWT ATs and authenticated encryption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 16:50:53 -0000 --0000000000006374f20585021f45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil, thanks! This does sound very interesting. Just to clarify, you would document this in a separate doc extending JOSE? We could then mention it from the JWT AT profile, whihc would remain lightweight and implementation independent. thanks V. On Tue, Mar 26, 2019 at 3:11 AM Neil Madden wrote: > There was a brief discussion at OSW about signing vs encryption for > JWT-based access tokens. I think it was Brian Campbell that pointed out > that you often want authenticated encryption rather than signing, and I > agree with this. > > Currently JOSE only supports authenticated encryption for symmetric > cryptography, which means that the AS and RS must agree a shared secret k= ey > beforehand. (Or else the RS uses the token introspection endpoint and > doesn=E2=80=99t decrypt the token itself). Symmetric cryptography is less= than > ideal when the AS and RS are in separate trust boundaries (e.g., differen= t > companies). > > There are actually ways to do *public key* authenticated encryption, but > JOSE doesn=E2=80=99t support them yet. I wrote a 3-part blog series about= this > recently [1], but I=E2=80=99ll summarise the tl;dr version here. I think = for > JWT-based access tokens that contain identity assertions, this is probabl= y > what you want in most cases as it provides both confidentiality and > authenticity without needing a bulky nested signed-then-encrypted JWT. Is > this something people would be interested in, if I propose a draft? > > Details: > > The basic idea is to introduce one or more variants on ECDH-ES that > provide sender authentication. The most straightforward is to use ECDH-SS= =E2=80=94 > i.e., Diffie-Hellman between two static key pairs, one for the sender and > one for the recipient, with no ephemeral keys. This provides authenticate= d > encryption so long as the content encryption method is authenticated (whi= ch > they all are in JOSE). But it has a number of security downsides, which I > describe in more detail in the blog. (It might be useful in some IoT > scenarios though). > > The better variant is to instead do ECDH-ESSS. That is, we generate a > random ephemeral key pair and do an agreement with the recipient=E2=80=99= s static > public key, just like in ECDH-ES, but then we do another key agreement > between the sender=E2=80=99s static private key and the recipient=E2=80= =99s static private > key. We then concatenate the two shared secrets and feed them into > ConcatKDF just like you would for ECDH-ES. This is what NIST SP.800-56A [= 2] > calls the =E2=80=9Cone-pass unified model=E2=80=9D (section 6.2.1.2). If = you squint a bit > then it is also very similar to the =E2=80=9CK=E2=80=9D one-way pattern i= n the Noise > protocol framework [3]. > > To spell it out, the process for encrypting a JWE with this new scheme is > as follows: > > Sender has long-term =E2=80=9Cstatic=E2=80=9D key pair: ssk,_spk (ssk =3D= sender secret key, > etc) > Recipient has long-term static key pair: rsk, rpk > > 1. Sender generates a random ephemeral key pair: esk, epk > 2. Calculate Ze :=3D ecdh(esk, rpk) =E2=80=94 just like in ECDH-ES > 3. Calculate Zs :=3D ecdh(ssk, rpk) > 4. Let Z =3D Ze || Zs where || is concatenation > 5. Run Z through ConcatKDF with PartyUInfo/PartyVInfo just as in ECDH-ES > 6. Encrypt the message using the chosen =E2=80=9Cenc=E2=80=9D encryption = method using the > key derived in step 5. > > On its own ECDH-ESSS has some decent security properties (including > authenticated encryption), but it is especially good when you want to > exchange lots of messages with the recipient. If the recipient replies to > your initial message using ECDH-ESSS but using the ephemeral public key y= ou > sent in the first message as if it was your static public key, then what > you get is an interactive handshake very similar to the Noise KK pattern > [4] (squinting quite hard at this point). Both parties can then use the > derived key from step 5 of the second message as a shared session key and > send =E2=80=9Cdirect=E2=80=9D encrypted JWEs to each other from that poin= t on. This > provides very strong security properties listed later in the Noise spec, > including forward secrecy and both sender and recipient authentication wi= th > resistance to key compromise impersonation. So beyond its usefulness for > Access Token JWTs, this scheme is a really versatile building block that > you can use for lots of advanced use-cases (e.g., PoP schemes). > > There are even nice formal models of the Noise handshake patterns in > ProVerif [5], but I think they are only valid for the specific details of > how Noise performs key derivation and transcript hashing so they wouldn= =E2=80=99t > directly apply to a JOSE version. > > [1] > https://neilmadden.blog/2018/11/14/public-key-authenticated-encryption-an= d-why-you-want-it-part-i/ > [2] > https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.p= df > [3] https://noiseprotocol.org/noise.html#one-way-handshake-patterns > [4] > https://noiseprotocol.org/noise.html#interactive-handshake-patterns-funda= mental > > [5] https://noiseexplorer.com > > Cheers, > > Neil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000006374f20585021f45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Neil,
    thanks! This does sound very interesting. Jus= t to clarify, you would document this in a separate doc extending JOSE?
    We could then mention it from the JWT AT profile, whihc would remain= lightweight and implementation independent.
    thanks
    V.<= /div>

    On Tue, Mar 26, 2019 at 3:11 AM Neil Madden <neil.madden@forgerock.com> wrote:
    There was a brief discussion at OSW about = signing vs encryption for JWT-based access tokens. I think it was Brian Cam= pbell that pointed out that you often want authenticated encryption rather = than signing, and I agree with this.

    <= div>Currently JOSE only supports authenticated encryption for symmetric cry= ptography, which means that the AS and RS must agree a shared secret key be= forehand. (Or else the RS uses the token introspection endpoint and doesn= =E2=80=99t decrypt the token itself). Symmetric cryptography is less than i= deal when the AS and RS are in separate trust boundaries (e.g., different c= ompanies).

    There are actually ways to do *public k= ey* authenticated encryption, but JOSE doesn=E2=80=99t support them yet. I = wrote a 3-part blog series about this recently [1], but I=E2=80=99ll summar= ise the tl;dr version here. I think for JWT-based access tokens that contai= n identity assertions, this is probably what you want in most cases as it p= rovides both confidentiality and authenticity without needing a bulky neste= d signed-then-encrypted JWT. Is this something people would be interested i= n, if I propose a draft?

    Details:

    The basic idea is to introduce one or more variants on ECDH-ES tha= t provide sender authentication. The most straightforward is to use ECDH-SS= =E2=80=94 i.e., Diffie-Hellman between two static key pairs, one for the s= ender and one for the recipient, with no ephemeral keys. This provides auth= enticated encryption so long as the content encryption method is authentica= ted (which they all are in JOSE). But it has a number of security downsides= , which I describe in more detail in the blog. (It might be useful in some = IoT scenarios though).

    The better variant is to in= stead do ECDH-ESSS. That is, we generate a random ephemeral key pair and do= an agreement with the recipient=E2=80=99s static public key, just like in = ECDH-ES, but then we do another key agreement between the sender=E2=80=99s = static private key and the recipient=E2=80=99s static private key. We then = concatenate the two shared secrets and feed them into ConcatKDF just like y= ou would for ECDH-ES. This is what NIST SP.800-56A [2] calls the =E2=80=9Co= ne-pass unified model=E2=80=9D (section 6.2.1.2). If you squint a bit then = it is also very similar to the =E2=80=9CK=E2=80=9D one-way pattern in the N= oise protocol framework [3].

    To spell it out, the = process for encrypting a JWE with this new scheme is as follows:
    =
    Sender has long-term =E2=80=9Cstatic=E2=80=9D key pair: ssk,= _spk (ssk =3D sender secret key, etc)
    Recipient has long-term sta= tic key pair: rsk, rpk

    1. Sender generates a rando= m ephemeral key pair: esk, epk
    2. Calculate Ze :=3D ecdh(esk, rpk= ) =C2=A0=E2=80=94 just like in ECDH-ES
    3. Calculate Zs :=3D ecdh(= ssk, rpk)
    4. Let Z =3D Ze || Zs where || is concatenation
    5. Run Z through ConcatKDF with PartyUInfo/PartyVInfo just as in ECDH-ES=
    6. Encrypt the message using the chosen =E2=80=9Cenc=E2=80=9D en= cryption method using the key derived in step 5.

    O= n its own ECDH-ESSS has some decent security properties (including authenti= cated encryption), but it is especially good when you want to exchange lots= of messages with the recipient. If the recipient replies to your initial m= essage using ECDH-ESSS but using the ephemeral public key you sent in the f= irst message as if it was your static public key, then what you get is an i= nteractive handshake very similar to the Noise KK pattern [4] (squinting qu= ite hard at this point). Both parties can then use the derived key from ste= p 5 of the second message as a shared session key and send =E2=80=9Cdirect= =E2=80=9D encrypted JWEs to each other from that point on. This provides ve= ry strong security properties listed later in the Noise spec, including for= ward secrecy and both sender and recipient authentication with resistance t= o key compromise impersonation. So beyond its usefulness for Access Token J= WTs, this scheme is a really versatile building block that you can use for = lots of advanced use-cases (e.g., PoP schemes).

    Th= ere are even nice formal models of the Noise handshake patterns in ProVerif= [5], but I think they are only valid for the specific details of how Noise= performs key derivation and transcript hashing so they wouldn=E2=80=99t di= rectly apply to a JOSE version.

    [1]=C2=A0https://neilmadden.blog/2018= /11/14/public-key-authenticated-encryption-and-why-you-want-it-part-i/<= /div>
    [3]=C2=A0<= a href=3D"https://noiseprotocol.org/noise.html#one-way-handshake-patterns" = target=3D"_blank">https://noiseprotocol.org/noise.html#one-way-handshake-pa= tterns=C2=A0

    Cheers,<= /div>

    Neil
    ____________________________= ___________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --0000000000006374f20585021f45-- From nobody Tue Mar 26 09:56:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98E7120679 for ; Tue, 26 Mar 2019 09:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.com 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 L2HRw6gugMP5 for ; Tue, 26 Mar 2019 09:56:39 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E923120689 for ; Tue, 26 Mar 2019 09:56:39 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id g1so8058428qki.5 for ; Tue, 26 Mar 2019 09:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4mYWu0Mi0HvPpFWk25P5FxHR62mRAw1EH5ZXpuHlLKs=; b=Djo+zMz0eepY/wnI2hE3ntbQzzmpJMukiHCpv9UvBO9KRR5UseoIL2CX1MTrzxWDVM 6KByQJEP3BNYuEMW8Aw2+FwOIk2LMdEzNI5PMbqLd+E+JxW2S5p45rTDfQ9FTWTZBWFc ybBpt9l+8D6hP76XoihRYM49/l9WGqr267CRMfEE7g0Rt5of8NFfs1dqKiLH6l2eTlmy 7xJRr1tqtLfRDKhHT69eAwDOQmlBwk3r79EJjY0ZYom0wfl2WvxNUbDRw3n9PJ/z8cag acUUvjQHDk9RsR/Hiv3yWQENhI+jeR1i49L5CuoA8tm1ed2RTod4qgfcNNeKV96iloHc vmfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4mYWu0Mi0HvPpFWk25P5FxHR62mRAw1EH5ZXpuHlLKs=; b=nxTsEd9uFg4aRj5wahGpUoLMOnUvyGdHx5Tj5BaoVPw4IbjS+wpB/PElliJr8HAoDP eHM+7jTK+qUxT2HfO1sb2T6oUry6nLzT6MxTN3VTMHmk6a7Qge+7g66YTmTTHZSQ/jRX 6CrOSuotsq8Y2+uMvWNqBdO2m8VYzdnSNFZsFC8t7bCMh1gbfZ2KqSg47HPTci7ZxYBH jCfBPOb5ZarfOVsgxBwRirk/L8lM2M9GxgD0MB2Q57Vzxxea1erbefifk6ReMpJcF9iQ bWoLT2pam8W0c3KacX1C6/EwLTl475g9+xQ6vYNUr7wsSyucLQ4jwQjXpCK5eqhgMiab migg== X-Gm-Message-State: APjAAAVe8cqsKMvkdaukNBAiYtG9Nbh7HQhtaFeNyo4bxu1yb6oaATQG vpQtdMiIyzzm4wsI9ZdYKa66DWsni5JQlOhWGoDapCfe X-Google-Smtp-Source: APXvYqw1VAk1yRhkU3HoVxdMloddmd72hx2U5WQa3hQKDzolwlU4yry4RVSTgSPTKjzSHl6MDPfHax80OIJfLM9te1I= X-Received: by 2002:a37:93c4:: with SMTP id v187mr23768807qkd.166.1553619398459; Tue, 26 Mar 2019 09:56:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hans Zandbelt Date: Tue, 26 Mar 2019 17:56:27 +0100 Message-ID: To: Vittorio Bertocci Cc: Steinar Noem , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000005c970d05850234d8" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 16:56:52 -0000 --0000000000005c970d05850234d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable great summary! this will hurt quite a few existing m2m deployments but I do like the rigidness of it all: it is very explicit, cannot misinterpreted and thus prevents failure (which is really what Dominick is after); I'm on board Hans. On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci wrote: > thank you Steinar and everyone else for the comments on this! > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, > Bertrand recommend using sub only for users. Martin would like to have th= e > sub for app only flows as well. Hans is neutral. > That does sound like the sub as user has more consensus, tho before > changing it I'd wait for the people currently at IETF104 to have more tim= e > to comment as well. > Clarification. If the goal is to be able to apply the logic "if there's a > sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use > of sub when that's not the case. Are all OK with it? > > Dave, the suggestion of having explicit typing for app only vs user only > is interesting! For the purpose of putting together an interoperable > profile, tho, I would suggest we table it for v1 in the interest of getti= ng > to something easy to adopt (hence with small delta vs existing > implementations) faster. > > On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote: > >> Hi Vittorio, we (the national federation-gateway for the health service= s >> in norway - "HelseID") think his is a really valuable initiative! >> We also agree with Dominick concerning definition of the "sub" claim. >> >> Steinar >> >> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier < >> dbaier@leastprivilege.com>: >> >>> From an access token consumer (aka API) developer point of view, I >>> prefer this logic >>> >>> "If sub is present - client acts on behalf of a user, if not - not." >>> >>> Anything more complicated has a potential of going wrong. >>> >>> >>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >>> >>> Hi Vittorio, >>> >>> Yeah, I=E2=80=99m concerning user & client ids collision. >>> I haven=E2=80=99t seen such implementations, but user-select username a= s sub, or >>> incremental integer as sub & client_id will be easily collide. >>> >>> If you can enforce collision resistant IDs between user & client >>> instances, it=E2=80=99ll works fine. I feel its overkill though. >>> >>> Sent from my iPhone >>> >>> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote: >>> >>> Hey Nov, Dominick, Hans- >>> thanks for the comments. That was an area I was expecting to cause more >>> discussion, and I am glad we are having this opportunity to clarify. >>> The current language in the draft traces the etymology of sub to OpenID >>> Connect core, hence Dominick observation is on point. However in the >>> description I express something in line with 7519, which was in fact my >>> intent. >>> >>> The idea was to provide an identifier of the calling subject that is >>> guaranteed to be present in all cases- this would allow an SDK develope= r to >>> use the same code for things like lookups and membership checks regardl= ess >>> of the nature of the caller (user in a delegated case, app in app-only >>> grants). The information to discriminate between user and app callers i= s >>> always available in the token (say, the caller is a user if sub!=3Dclie= nt_id, >>> where client_id is always guaranteed to be present as well) hence there= 's >>> no loss in expressive power, should that difference be relevant for the >>> resource server. >>> >>> Dominick, Hans- I probably missed the security issue you guys are >>> thinking of in this case. Of course, if this would introduce a risk I >>> completely agree it should be changed- I'd just like to understand bett= er >>> the problem. Could you expand it in a scenario/use case to clarify the = risk? >>> Nov- playing this back: is the concern that a user and a client might >>> have the same identifier within an IDP? When using collision resistant = IDs, >>> as it is usually the case, that seems to be a remote possibility- did y= ou >>> stumble in such scenario in production? >>> >>> Thanks >>> V. >>> >>> >>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt < >>> hans.zandbelt@zmartzone.eu> wrote: >>> >>>> I believe there are plenty of OAuth 2.0 only use cases out there... bu= t >>>> nevertheless I agree with the potential confusion and thus security >>>> problems arising from that (though one may argue the semantics are the >>>> same). >>>> >>>> Hans. >>>> >>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier < >>>> dbaier@leastprivilege.com> wrote: >>>> >>>>> Yes I know - and I think in hindsight it was a mistake to use the sam= e >>>>> claim type for multiple semantics. >>>>> >>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making= things more >>>>> complicated than they need to be - in my experience almost no-one (th= at I >>>>> know) does OIDC only - nor OAuth only. They always combine it. >>>>> >>>>> In reality this leads to potential security problems - this spec has >>>>> the potential to rectify the situation. >>>>> >>>>> Dominick >>>>> >>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ( >>>>> hans.zandbelt@zmartzone.eu) wrote: >>>>> >>>>> Without agreeing or disagreeing: OIDC does not apply here since it is >>>>> not OAuth and an access token is not an id_token. >>>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.= 2 >>>>> : >>>>> >>>>> "The "sub" (subject) claim identifies the principal that is the >>>>> subject of the JWT. The claims in a JWT are normally statements >>>>> about the subject. The subject value MUST either be scoped to be >>>>> locally unique in the context of the issuer or be globally unique. >>>>> The processing of this claim is generally application specific" >>>>> >>>>> which kind of spells "client" in case of the client credentials grant >>>>> but I also do worry about Resource Servers thinking/acting only in te= rms of >>>>> users >>>>> >>>>> Hans. >>>>> >>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>>>> dbaier@leastprivilege.com> wrote: >>>>> >>>>>> IMHO the sub claim should always refer to the user - and nothing els= e. >>>>>> >>>>>> OIDC says: >>>>>> >>>>>> "Subject - Identifier for the End-User at the Issuer." >>>>>> >>>>>> client_id should be used to identify clients. >>>>>> >>>>>> cheers >>>>>> Dominick >>>>>> >>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>>>>> >>>>>> Hi Vittorio, >>>>>> >>>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>>> >>>>>> One feedback. >>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, e= nd-user and >>>>>> client, in this spec. >>>>>> It requires those 2 types of identifiers to be unique each other in >>>>>> the IdP context. >>>>>> >>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, s= o that no such >>>>>> constraint needed. >>>>>> >>>>>> thanks >>>>>> >>>>>> nov >>>>>> >>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>>>>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> Dear all, >>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 >>>>>> access tokens. You can find it in >>>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-j= wt/ >>>>>> . >>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be >>>>>> presenting remotely). I look forward for your comments! >>>>>> >>>>>> Here's just a bit of backstory, in case you are interested in how >>>>>> this doc came to be. The trajectory it followed is somewhat unusual. >>>>>> >>>>>> - Despite OAuth2 not requiring any specific format for ATs, >>>>>> through the years I have come across multiple proprietary solutio= n using >>>>>> JWT for their access token. The intent and scenarios addressed by= those >>>>>> solutions are mostly the same across vendors, but the syntax and >>>>>> interpretations in the implementations are different enough to pr= event >>>>>> developers from reusing code and skills when moving from product = to product. >>>>>> - I asked several individuals from key products and services to >>>>>> share with me concrete examples of their JWT access tokens (THANK= YOU >>>>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens = and >>>>>> explanations!). >>>>>> I studied and compared all those instances, identifying >>>>>> commonalities and differences. >>>>>> - I put together a presentation summarizing my findings and >>>>>> suggesting a rough interoperable profile (slides: >>>>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocc= i_-_a_jwt_profile_for_ats.pptx >>>>>> >>>>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>>>> - The presentation was followed up by 1.5 hours of unconference >>>>>> discussion, which was incredibly valuable to get tight-loop feedb= ack and >>>>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhu= vinov, >>>>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all >>>>>> there and contributed generously to the discussion. Thank you!!! >>>>>> Note: if you were at OSW2019, participated in the discussion and >>>>>> didn't get credited in the draft, my apologies: please send me a = note and >>>>>> I'll make things right at the next update. >>>>>> - On my flight back I did my best to incorporate all the ideas >>>>>> and feedback in a draft, which will be discussed at IETF104 tomor= row. >>>>>> Rifaat, Hannes and above all Brian were all super helpful in nego= tiating >>>>>> the mysterious syntax of the RFC format and submission process. >>>>>> >>>>>> I was blown away by the availability, involvement and willingness to >>>>>> invest time to get things right that everyone demonstrated in the pr= ocess. >>>>>> This is an amazing community. >>>>>> V. >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> >>>>> -- >>>>> hans.zandbelt@zmartzone.eu >>>>> ZmartZone IAM - www.zmartzone.eu >>>>> >>>>> >>>> >>>> -- >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> -- >> Vennlig hilsen >> >> Steinar Noem >> Partner Udelt AS >> Systemutvikler >> >> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 >> | www.udelt.no | >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --0000000000005c970d05850234d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    great summary! this will hurt quite a few= existing m2m deployments but I do like the rigidness of it all: it is very= explicit, cannot misinterpreted and thus prevents failure (which is really= what Dominick is after); I'm on board

    Hans.

    On= Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:=
    thank you Steinar and everyone else for the comments on this!
    To summ= arize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand re= commend using sub only for users. Martin would like to have the sub for app= only flows as well. Hans is neutral.
    That does sound like the su= b as user has more consensus, tho before changing it I'd wait for the p= eople currently at IETF104 to have more time to comment as well.
    = Clarification. If the goal is to be able to apply the logic "if there&= #39;s a sub, it's a user flow", we have to explicitly disallow (MU= ST NOT) the use of sub when that's not the case. Are all OK with it?

    Dave, the suggestion of having explicit typing for a= pp only vs user only is interesting! For the purpose of putting together an= interoperable profile, tho, I would suggest we table it for v1 in the inte= rest of getting to something easy to adopt (hence with small delta vs exist= ing implementations) faster.=C2=A0 =C2=A0 =C2=A0

    On Tue, Mar 26, 2019= at 1:40 AM Steinar Noem <steinar@udelt.no> wrote:
    Hi Vittorio, we=C2=A0 (the national federation-gateway for the health services in norway - "= HelseID")=C2=A0 think his is a really valuable initiative!
    We also= agree with Dominick concerning definition of the "sub" claim.

    <mvh>Steinar</mvh>

    tir. 26. mar. 20= 19 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com>:
    From an access token consumer (aka API) de= veloper point of view, I prefer this logic

    "If sub is present - client acts on behalf of = a user, if not - not."

    Anything more complicated has a potential of going wrong.

    On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

    =
    Hi Vittorio,

    Yeah, I=E2=80=99m concerning user & client ids collision.
    I haven=E2=80=99t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

    If you can enforce collision resistant IDs between user & client instances, it=E2=80=99ll works fine. I feel its overkill though.

    Sent from my iPhone

    On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

    Hey Nov, Dominick, Hans-
    thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
    The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

    The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

    Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
    Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

    Thanks
    V.=C2=A0


    On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
    I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

    Hans.

    On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

    All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

    In reality this leads to potential security problems - this spec has the potential to rectify the situation.

    Dominick

    On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

    Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
    "The "sub" (subject) claim identifies the princip= al that is the
    =C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are normally statements
    =C2=A0 =C2=A0about the subject.=C2=A0 The subject value MUST either be scoped to be
    =C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
    =C2=A0 =C2=A0The processing of this claim is generally application specific"

    which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

    Hans.
    On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    IMHO the sub claim should always refer to the user - and nothing else.

    OIDC says:

    "Subject - Identifier for the End-User at the Issuer."

    client_id should be used to identify clients.

    cheers
    Dominick

    On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Thanks for the good starting point of standardizing JWT-ized AT.

    One feedback.
    The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
    It requires those 2 types of identifiers to be unique each other in the IdP context.

    I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

    thanks

    nov
    On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
    Dear all,
    I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
    I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

    Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
    I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
    V.
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --


    --
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --
    Vennlig hilsen

    Steinar Noem
    Partner Udelt AS
    Systemutvikler
    =C2=A0
    |=C2=A0stei= nar@udelt.no=C2=A0|=C2=A0hei@udelt.no=C2=A0=C2=A0|= =C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.no=C2=A0|=C2= =A0
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --
    --0000000000005c970d05850234d8-- From nobody Tue Mar 26 09:57:48 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0A3120673 for ; Tue, 26 Mar 2019 09:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk 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 2U5mPDqMOTEg for ; Tue, 26 Mar 2019 09:57:32 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB281206C5 for ; Tue, 26 Mar 2019 09:57:31 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id u68so9228880lff.7 for ; Tue, 26 Mar 2019 09:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sfK5anuedVALsuVqkw56zEewFsen3vkt2znHPWV96Dg=; b=UEEf8ajVZUpMM7N8djA5jkZYunUHtTNP/iJ5e7bESmdb+GueL8xUGr3WJ0bGxOb9AI K5lvOVMp+96h8G29L83+x6Bo54dFfHT7WyOVPfknZ9cB2YZsLWv/yvb7pdKsQAhTVP3p JqYgroZTiTxgxY/8CmAMS/OQ8WQ9A5jrGymUI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sfK5anuedVALsuVqkw56zEewFsen3vkt2znHPWV96Dg=; b=tbz+y7OfbI4dM1I66VCO+34/NoJfkqRLm5fQW2LiD3NpAyaFkwykzT3Rvn1BiykEtL s/mgYO7pw/FSBpFgX2SI6qrcdosAowrTiHDAAjmJyCNAppsBSkk1R1hMEvk+3b+NFt0a zqODK9QxCZ66MXGVq9PxH6mjx3kERaYZVmPDdxzleIUbMxhhgx/4rkabnipSNmF1rR1f LTnguBgNHx4u859CZmIljCKPITWT6Oe5nOXTt0qfUsFhPqYF+Gz92V/z6kvbmlI1mZuB U9vr314cSXsLz3yI7woA9LQDtzz1IM5FG9qsTpJrkB7vqHQaRNjMvc5h4A5DWESCvsJj pdNA== X-Gm-Message-State: APjAAAUB0K/cA3F3fWIgacrVBfm3590T+zEBLqj9MTCjhStYNWave25b HkLVRMj6PJNlF9C9oU5AYY5Cfck51gAlIlUWGB0lHQ== X-Google-Smtp-Source: APXvYqw4yWPh3btkd0BLiOidNLr4fXf9ofehWWBpmnbJgEzZ1RBmAjy+PHYMX5JHajFCs0PG4NIsVjl/jFq2w0Gu9uI= X-Received: by 2002:a19:550d:: with SMTP id n13mr16864533lfe.26.1553619449614; Tue, 26 Mar 2019 09:57:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Tonge Date: Tue, 26 Mar 2019 17:57:18 +0100 Message-ID: To: Vittorio Bertocci Cc: Steinar Noem , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000006936cf05850237f3" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 16:57:46 -0000 --0000000000006936cf05850237f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vittorio My understanding from Rob and others is that `sub` is already used for tokens issued via the client credentials grant (in fact looking at the tables from your presentation, most examples used `sub` for both user identity and client identity). Given the desire for a spec that doesn't break existing implementations, perhaps a new claim indicating the type of access token would allow for better interoperability. Dave On Tue, 26 Mar 2019 at 17:48, Vittorio Bertocci wrote: > thank you Steinar and everyone else for the comments on this! > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, > Bertrand recommend using sub only for users. Martin would like to have th= e > sub for app only flows as well. Hans is neutral. > That does sound like the sub as user has more consensus, tho before > changing it I'd wait for the people currently at IETF104 to have more tim= e > to comment as well. > Clarification. If the goal is to be able to apply the logic "if there's a > sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use > of sub when that's not the case. Are all OK with it? > > Dave, the suggestion of having explicit typing for app only vs user only > is interesting! For the purpose of putting together an interoperable > profile, tho, I would suggest we table it for v1 in the interest of getti= ng > to something easy to adopt (hence with small delta vs existing > implementations) faster. > > On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote: > >> Hi Vittorio, we (the national federation-gateway for the health service= s >> in norway - "HelseID") think his is a really valuable initiative! >> We also agree with Dominick concerning definition of the "sub" claim. >> >> Steinar >> >> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier < >> dbaier@leastprivilege.com>: >> >>> From an access token consumer (aka API) developer point of view, I >>> prefer this logic >>> >>> "If sub is present - client acts on behalf of a user, if not - not." >>> >>> Anything more complicated has a potential of going wrong. >>> >>> >>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >>> >>> Hi Vittorio, >>> >>> Yeah, I=E2=80=99m concerning user & client ids collision. >>> I haven=E2=80=99t seen such implementations, but user-select username a= s sub, or >>> incremental integer as sub & client_id will be easily collide. >>> >>> If you can enforce collision resistant IDs between user & client >>> instances, it=E2=80=99ll works fine. I feel its overkill though. >>> >>> Sent from my iPhone >>> >>> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote: >>> >>> Hey Nov, Dominick, Hans- >>> thanks for the comments. That was an area I was expecting to cause more >>> discussion, and I am glad we are having this opportunity to clarify. >>> The current language in the draft traces the etymology of sub to OpenID >>> Connect core, hence Dominick observation is on point. However in the >>> description I express something in line with 7519, which was in fact my >>> intent. >>> >>> The idea was to provide an identifier of the calling subject that is >>> guaranteed to be present in all cases- this would allow an SDK develope= r to >>> use the same code for things like lookups and membership checks regardl= ess >>> of the nature of the caller (user in a delegated case, app in app-only >>> grants). The information to discriminate between user and app callers i= s >>> always available in the token (say, the caller is a user if sub!=3Dclie= nt_id, >>> where client_id is always guaranteed to be present as well) hence there= 's >>> no loss in expressive power, should that difference be relevant for the >>> resource server. >>> >>> Dominick, Hans- I probably missed the security issue you guys are >>> thinking of in this case. Of course, if this would introduce a risk I >>> completely agree it should be changed- I'd just like to understand bett= er >>> the problem. Could you expand it in a scenario/use case to clarify the = risk? >>> Nov- playing this back: is the concern that a user and a client might >>> have the same identifier within an IDP? When using collision resistant = IDs, >>> as it is usually the case, that seems to be a remote possibility- did y= ou >>> stumble in such scenario in production? >>> >>> Thanks >>> V. >>> >>> >>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt < >>> hans.zandbelt@zmartzone.eu> wrote: >>> >>>> I believe there are plenty of OAuth 2.0 only use cases out there... bu= t >>>> nevertheless I agree with the potential confusion and thus security >>>> problems arising from that (though one may argue the semantics are the >>>> same). >>>> >>>> Hans. >>>> >>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier < >>>> dbaier@leastprivilege.com> wrote: >>>> >>>>> Yes I know - and I think in hindsight it was a mistake to use the sam= e >>>>> claim type for multiple semantics. >>>>> >>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making= things more >>>>> complicated than they need to be - in my experience almost no-one (th= at I >>>>> know) does OIDC only - nor OAuth only. They always combine it. >>>>> >>>>> In reality this leads to potential security problems - this spec has >>>>> the potential to rectify the situation. >>>>> >>>>> Dominick >>>>> >>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ( >>>>> hans.zandbelt@zmartzone.eu) wrote: >>>>> >>>>> Without agreeing or disagreeing: OIDC does not apply here since it is >>>>> not OAuth and an access token is not an id_token. >>>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.= 2 >>>>> : >>>>> >>>>> "The "sub" (subject) claim identifies the principal that is the >>>>> subject of the JWT. The claims in a JWT are normally statements >>>>> about the subject. The subject value MUST either be scoped to be >>>>> locally unique in the context of the issuer or be globally unique. >>>>> The processing of this claim is generally application specific" >>>>> >>>>> which kind of spells "client" in case of the client credentials grant >>>>> but I also do worry about Resource Servers thinking/acting only in te= rms of >>>>> users >>>>> >>>>> Hans. >>>>> >>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>>>> dbaier@leastprivilege.com> wrote: >>>>> >>>>>> IMHO the sub claim should always refer to the user - and nothing els= e. >>>>>> >>>>>> OIDC says: >>>>>> >>>>>> "Subject - Identifier for the End-User at the Issuer." >>>>>> >>>>>> client_id should be used to identify clients. >>>>>> >>>>>> cheers >>>>>> Dominick >>>>>> >>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>>>>> >>>>>> Hi Vittorio, >>>>>> >>>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>>> >>>>>> One feedback. >>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, e= nd-user and >>>>>> client, in this spec. >>>>>> It requires those 2 types of identifiers to be unique each other in >>>>>> the IdP context. >>>>>> >>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, s= o that no such >>>>>> constraint needed. >>>>>> >>>>>> thanks >>>>>> >>>>>> nov >>>>>> >>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>>>>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>>>>> >>>>>> Dear all, >>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 >>>>>> access tokens. You can find it in >>>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-j= wt/ >>>>>> . >>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be >>>>>> presenting remotely). I look forward for your comments! >>>>>> >>>>>> Here's just a bit of backstory, in case you are interested in how >>>>>> this doc came to be. The trajectory it followed is somewhat unusual. >>>>>> >>>>>> - Despite OAuth2 not requiring any specific format for ATs, >>>>>> through the years I have come across multiple proprietary solutio= n using >>>>>> JWT for their access token. The intent and scenarios addressed by= those >>>>>> solutions are mostly the same across vendors, but the syntax and >>>>>> interpretations in the implementations are different enough to pr= event >>>>>> developers from reusing code and skills when moving from product = to product. >>>>>> - I asked several individuals from key products and services to >>>>>> share with me concrete examples of their JWT access tokens (THANK= YOU >>>>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens = and >>>>>> explanations!). >>>>>> I studied and compared all those instances, identifying >>>>>> commonalities and differences. >>>>>> - I put together a presentation summarizing my findings and >>>>>> suggesting a rough interoperable profile (slides: >>>>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocc= i_-_a_jwt_profile_for_ats.pptx >>>>>> >>>>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>>>> - The presentation was followed up by 1.5 hours of unconference >>>>>> discussion, which was incredibly valuable to get tight-loop feedb= ack and >>>>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhu= vinov, >>>>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all >>>>>> there and contributed generously to the discussion. Thank you!!! >>>>>> Note: if you were at OSW2019, participated in the discussion and >>>>>> didn't get credited in the draft, my apologies: please send me a = note and >>>>>> I'll make things right at the next update. >>>>>> - On my flight back I did my best to incorporate all the ideas >>>>>> and feedback in a draft, which will be discussed at IETF104 tomor= row. >>>>>> Rifaat, Hannes and above all Brian were all super helpful in nego= tiating >>>>>> the mysterious syntax of the RFC format and submission process. >>>>>> >>>>>> I was blown away by the availability, involvement and willingness to >>>>>> invest time to get things right that everyone demonstrated in the pr= ocess. >>>>>> This is an amazing community. >>>>>> V. >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> >>>>> -- >>>>> hans.zandbelt@zmartzone.eu >>>>> ZmartZone IAM - www.zmartzone.eu >>>>> >>>>> >>>> >>>> -- >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> -- >> Vennlig hilsen >> >> Steinar Noem >> Partner Udelt AS >> Systemutvikler >> >> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 >> | www.udelt.no | >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2018 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --0000000000006936cf05850237f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Vittorio

    My understanding from Rob and o= thers is that `sub` is already used for tokens issued via the client creden= tials grant (in fact looking at the tables from your presentation, most exa= mples used `sub` for both user identity and client identity). Given the des= ire for a spec that doesn't break existing implementations, perhaps a n= ew claim indicating the type of access token would allow for better interop= erability.

    Dave

    On Tue, 26 Mar 2019 at 17:48, Vittorio = Bertocci <Vittorio=3D40aut= h0.com@dmarc.ietf.org> wrote:
    thank you Steinar and everyone else f= or the comments on this!
    To summarize the situation so far: Dominick, S= teinar, Rob, David, Nov, Bertrand recommend using sub only for users. Marti= n would like to have the sub for app only flows as well. Hans is neutral.
    That does sound like the sub as user has more consensus, tho befor= e changing it I'd wait for the people currently at IETF104 to have more= time to comment as well.
    Clarification. If the goal is to be abl= e to apply the logic "if there's a sub, it's a user flow"= , we have to explicitly disallow (MUST NOT) the use of sub when that's = not the case. Are all OK with it?

    Dave, the sugges= tion of having explicit typing for app only vs user only is interesting! Fo= r the purpose of putting together an interoperable profile, tho, I would su= ggest we table it for v1 in the interest of getting to something easy to ad= opt (hence with small delta vs existing implementations) faster.=C2=A0 =C2= =A0 =C2=A0

    On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no> wrote:=
    Hi Vittorio, we=C2=A0 (the national federation-gateway for the health services in norway - "= HelseID")=C2=A0 think his is a really valuable initiative!
    We also= agree with Dominick concerning definition of the "sub" claim.

    <mvh>Steinar</mvh>

    tir. 26. mar. 20= 19 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com>:
    From an access token consumer (aka API) de= veloper point of view, I prefer this logic

    "If sub is present - client acts on behalf of = a user, if not - not."

    Anything more complicated has a potential of going wrong.

    On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

    =
    Hi Vittorio,

    Yeah, I=E2=80=99m concerning user & client ids collision.
    I haven=E2=80=99t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

    If you can enforce collision resistant IDs between user & client instances, it=E2=80=99ll works fine. I feel its overkill though.

    Sent from my iPhone

    On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

    Hey Nov, Dominick, Hans-
    thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
    The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

    The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

    Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
    Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

    Thanks
    V.=C2=A0


    On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
    I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

    Hans.

    On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

    All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

    In reality this leads to potential security problems - this spec has the potential to rectify the situation.

    Dominick

    On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

    Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
    "The "sub" (subject) claim identifies the princip= al that is the
    =C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are normally statements
    =C2=A0 =C2=A0about the subject.=C2=A0 The subject value MUST either be scoped to be
    =C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
    =C2=A0 =C2=A0The processing of this claim is generally application specific"

    which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

    Hans.
    On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    IMHO the sub claim should always refer to the user - and nothing else.

    OIDC says:

    "Subject - Identifier for the End-User at the Issuer."

    client_id should be used to identify clients.

    cheers
    Dominick

    On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Thanks for the good starting point of standardizing JWT-ized AT.

    One feedback.
    The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
    It requires those 2 types of identifiers to be unique each other in the IdP context.

    I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

    thanks

    nov
    On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
    Dear all,
    I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
    I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

    Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
    I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
    V.
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --


    --
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --
    Vennlig hilsen

    Steinar Noem
    Partner Udelt AS
    Systemutvikler
    =C2=A0
    |=C2=A0stei= nar@udelt.no=C2=A0|=C2=A0hei@udelt.no=C2=A0=C2=A0|= =C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.no=C2=A0|=C2= =A0
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --
    Da= ve Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5th Fl= oor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 512= 0

    Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited whic= h is authorised and regulated by the Financial Conduct Authority ("FCA= ").=C2=A0Moneyhub Financial Technology is entered on the Financial Ser= vices Register=C2=A0(FRN=C2=A0809360) at fca.= org.uk/register. Moneyhub=C2=A0Financial Technology is registered in England &= ; Wales, company registration number=C2=A0=C2=A006909772=C2=A0.<= /span>
    Moneyhub=C2=A0Financial Technology L= imited 2018=C2=A0=C2=A9<= /div>

    DISCLAIMER: This email (including any attachments) is subject to co= pyright, and the information in it is confidential. Use of this email or of= any information in it other than by the addressee is unauthorised and unla= wful. Whilst reasonable efforts are made to ensure that any attachments are= virus-free, it is the recipient's sole responsibility to scan all atta= chments for viruses. All calls and emails to and from this company may be m= onitored and recorded for legitimate purposes relating to this company'= s business. Any opinions expressed in this email (or in any attachments) ar= e those of the author and do not necessarily represent the opinions of Mone= yhub Financial Technology Limited or of any other group company.
    <= /div>
    --0000000000006936cf05850237f3-- From nobody Tue Mar 26 10:00:37 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C651E1205F8 for ; Tue, 26 Mar 2019 10:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=unavailable 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 asnyi-Kufge7 for ; Tue, 26 Mar 2019 10:00:31 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 2E7CA1203E3 for ; Tue, 26 Mar 2019 10:00:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2H7BACbWZpc/xwBYJlaBAYcAQEBBAE?= =?us-ascii?q?BBwQBAYFlgWcqaIEDJwqEBGKCaIUxjC4lfog6jxeBQiUKBRgNCYECgnZGAoU?= =?us-ascii?q?jIjgSAQEDAQEJAQMCAgJpHAyCeDEcPgEBAQEBASYBAQEBAQEBIwIIDB8REgI?= =?us-ascii?q?YAQEBAwEBASEmJQMIBQsCAQgYKgICIQYLJQIEDgUOBgeDBwGBXQMNBwEPrSS?= =?us-ascii?q?BL4NzUUFBgjwNghAPgS+BSYMShleBWD6BEScME4FOSTU+ghpHAQECAQGBJQ0?= =?us-ascii?q?PBghGBoJMMYImA4pchx+SaDYDBAICgSSDO4IPc4gagz4SB4IChX2DIYYIglq?= =?us-ascii?q?MNIRvgTqIKQGDcIFkIjGBJXFFCgUlAVUdgSYpCYINF4EAAQ6Cb06DcCOFPz8?= =?us-ascii?q?BATEBAY8bgR8BAQ?= X-IPAS-Result: =?us-ascii?q?A2H7BACbWZpc/xwBYJlaBAYcAQEBBAEBBwQBAYFlgWcqa?= =?us-ascii?q?IEDJwqEBGKCaIUxjC4lfog6jxeBQiUKBRgNCYECgnZGAoUjIjgSAQEDAQEJA?= =?us-ascii?q?QMCAgJpHAyCeDEcPgEBAQEBASYBAQEBAQEBIwIIDB8REgIYAQEBAwEBASEmJ?= =?us-ascii?q?QMIBQsCAQgYKgICIQYLJQIEDgUOBgeDBwGBXQMNBwEPrSSBL4NzUUFBgjwNg?= =?us-ascii?q?hAPgS+BSYMShleBWD6BEScME4FOSTU+ghpHAQECAQGBJQ0PBghGBoJMMYImA?= =?us-ascii?q?4pchx+SaDYDBAICgSSDO4IPc4gagz4SB4IChX2DIYYIglqMNIRvgTqIKQGDc?= =?us-ascii?q?IFkIjGBJXFFCgUlAVUdgSYpCYINF4EAAQ6Cb06DcCOFPz8BATEBAY8bgR8BA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.60,273,1549926000"; d="asc'?scan'208";a="14159280" Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2019 18:00:27 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAwDYWZpcfRBhWMBaBAYcAQEBBAE?= =?us-ascii?q?BBwQBAYFlgWeBEnESJwqEBGKIGYwuJX6IOo8XgWcKBRgNhAFGAoVEOBIBAQM?= =?us-ascii?q?BAQkBAwIUAQEWOiMMhUoBAQEDAQEBISYlAwgFCwIBCBgqAgIhBgslAgQOBQ4?= =?us-ascii?q?GB4MHAYFdAw0ID60igS+EREFBgjwNghAPgS+BSYMSiC8+gREnDBOBTkk1PoI?= =?us-ascii?q?aRwEBAgEBgSUNDwYIRgaCTDGCJgOKXIcfkmg2AwQCAoEkgzuCD3OIGoM+Ege?= =?us-ascii?q?CAoV9gyGGCIJajDSEb4E6jBqBZCAygSVxRQoFJQFVHYEmKQmCDReBAAEOgm9?= =?us-ascii?q?Og3AjhT8/AQIwAQGPG4EfAQE?= X-IronPort-AV: E=Sophos;i="5.60,273,1549926000"; d="asc'?scan'208";a="19635346" Received: from fgdemucivp01ltm.xch.fraunhofer.de (HELO FGDEMUCIMP12EXC.ads.fraunhofer.de) ([192.88.97.16]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/AES256-SHA; 26 Mar 2019 18:00:25 +0100 Received: from FGDEMUCIMP02EXC.ads.fraunhofer.de ([10.80.232.41]) by FGDEMUCIMP12EXC.ads.fraunhofer.de ([10.80.232.43]) with mapi id 14.03.0435.000; Tue, 26 Mar 2019 18:00:25 +0100 From: "Schanzenbach, Martin" To: Vittorio Bertocci CC: Steinar Noem , IETF oauth WG Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 Thread-Index: AQHU42Wr/thS5xrVIYxSuUg+/ebS0aYc/+GAgABhiACAACYMAIAAiF0AgAADbQA= Date: Tue, 26 Mar 2019 17:00:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.80.233.51] x-tm-as-product-ver: SMEX-11.0.0.4179-8.200.1013-24510.005 x-tm-as-result: No--42.121800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_EE9EA122-30F9-4B7E-B30C-B54FD5C5FBB8"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 17:00:36 -0000 --Apple-Mail=_EE9EA122-30F9-4B7E-B30C-B54FD5C5FBB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26. Mar 2019, at 17:48, Vittorio Bertocci = wrote: >=20 > thank you Steinar and everyone else for the comments on this! > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, = Bertrand recommend using sub only for users. Martin would like to have = the sub for app only flows as well. Hans is neutral. I am also neutral to this change in general. I was just noting that in = RFC7523 in combination with client credentials + JWT bearer token grant, = the JWT MUST contain a "sub" claim with the client_id. So, imo it is a little inconsistent if the JWT access token does not = contain a "sub" claim with client ID when it contains claims for the = client (as there is no user context). Hans also pointed out the JWT spec which supports this logic. In other words, if you think that the use of "sub" is consistent across = RFC7523 and your draft, it is fine with me and we will adopt our use = accordingly eventually. > That does sound like the sub as user has more consensus, tho before = changing it I'd wait for the people currently at IETF104 to have more = time to comment as well. > Clarification. If the goal is to be able to apply the logic "if = there's a sub, it's a user flow", we have to explicitly disallow (MUST = NOT) the use of sub when that's not the case. Are all OK with it? >=20 > Dave, the suggestion of having explicit typing for app only vs user = only is interesting! For the purpose of putting together an = interoperable profile, tho, I would suggest we table it for v1 in the = interest of getting to something easy to adopt (hence with small delta = vs existing implementations) faster. >=20 > On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote: > Hi Vittorio, we (the national federation-gateway for the health = services in norway - "HelseID") think his is a really valuable = initiative! > We also agree with Dominick concerning definition of the "sub" claim. >=20 > Steinar >=20 > tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier = : > =46rom an access token consumer (aka API) developer point of view, I = prefer this logic >=20 > "If sub is present - client acts on behalf of a user, if not - not." >=20 > Anything more complicated has a potential of going wrong. >=20 >=20 > On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >=20 >> Hi Vittorio, >>=20 >> Yeah, I=E2=80=99m concerning user & client ids collision. >> I haven=E2=80=99t seen such implementations, but user-select username = as sub, or incremental integer as sub & client_id will be easily = collide. >>=20 >> If you can enforce collision resistant IDs between user & client = instances, it=E2=80=99ll works fine. I feel its overkill though. >>=20 >> Sent from my iPhone >>=20 >> On Mar 26, 2019, at 8:51, Vittorio Bertocci = wrote: >>=20 >>> Hey Nov, Dominick, Hans- >>> thanks for the comments. That was an area I was expecting to cause = more discussion, and I am glad we are having this opportunity to = clarify. >>> The current language in the draft traces the etymology of sub to = OpenID Connect core, hence Dominick observation is on point. However in = the description I express something in line with 7519, which was in fact = my intent. >>>=20 >>> The idea was to provide an identifier of the calling subject that is = guaranteed to be present in all cases- this would allow an SDK developer = to use the same code for things like lookups and membership checks = regardless of the nature of the caller (user in a delegated case, app in = app-only grants). The information to discriminate between user and app = callers is always available in the token (say, the caller is a user if = sub!=3Dclient_id, where client_id is always guaranteed to be present as = well) hence there's no loss in expressive power, should that difference = be relevant for the resource server. >>>=20 >>> Dominick, Hans- I probably missed the security issue you guys are = thinking of in this case. Of course, if this would introduce a risk I = completely agree it should be changed- I'd just like to understand = better the problem. Could you expand it in a scenario/use case to = clarify the risk? >>> Nov- playing this back: is the concern that a user and a client = might have the same identifier within an IDP? When using collision = resistant IDs, as it is usually the case, that seems to be a remote = possibility- did you stumble in such scenario in production? >>>=20 >>> Thanks >>> V. >>>=20 >>>=20 >>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt = wrote: >>> I believe there are plenty of OAuth 2.0 only use cases out there... = but nevertheless I agree with the potential confusion and thus security = problems arising from that (though one may argue the semantics are the = same). >>>=20 >>> Hans. >>>=20 >>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier = wrote: >>> Yes I know - and I think in hindsight it was a mistake to use the = same claim type for multiple semantics. >>>=20 >>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are = making things more complicated than they need to be - in my experience = almost no-one (that I know) does OIDC only - nor OAuth only. They always = combine it. >>>=20 >>> In reality this leads to potential security problems - this spec has = the potential to rectify the situation. >>>=20 >>> Dominick >>>=20 >>> On 25. March 2019 at 14:58:56, Hans Zandbelt = (hans.zandbelt@zmartzone.eu) wrote: >>>=20 >>>> Without agreeing or disagreeing: OIDC does not apply here since it = is not OAuth and an access token is not an id_token. >>>> The JWT spec says in = https://tools.ietf.org/html/rfc7519#section-4.1.2: >>>>=20 >>>> "The "sub" (subject) claim identifies the principal that is the >>>> subject of the JWT. The claims in a JWT are normally statements >>>> about the subject. The subject value MUST either be scoped to = be >>>> locally unique in the context of the issuer or be globally = unique. >>>> The processing of this claim is generally application specific" >>>>=20 >>>> which kind of spells "client" in case of the client credentials = grant but I also do worry about Resource Servers thinking/acting only in = terms of users >>>>=20 >>>> Hans. >>>>=20 >>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier = wrote: >>>> IMHO the sub claim should always refer to the user - and nothing = else. >>>>=20 >>>> OIDC says: >>>>=20 >>>> "Subject - Identifier for the End-User at the Issuer." >>>>=20 >>>> client_id should be used to identify clients. >>>>=20 >>>> cheers >>>> Dominick >>>>=20 >>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) = wrote: >>>>=20 >>>>> Hi Vittorio, >>>>>=20 >>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>>=20 >>>>> One feedback. >>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and client, in this spec. >>>>> It requires those 2 types of identifiers to be unique each other = in the IdP context. >>>>>=20 >>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, = so that no such constraint needed. >>>>>=20 >>>>> thanks >>>>>=20 >>>>> nov >>>>>=20 >>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci = wrote: >>>>>>=20 >>>>>> Dear all, >>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 = access tokens. You can find it in = https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be = presenting remotely). I look forward for your comments! >>>>>>=20 >>>>>> Here's just a bit of backstory, in case you are interested in how = this doc came to be. The trajectory it followed is somewhat unusual. >>>>>> =E2=80=A2 Despite OAuth2 not requiring any specific format for = ATs, through the years I have come across multiple proprietary solution = using JWT for their access token. The intent and scenarios addressed by = those solutions are mostly the same across vendors, but the syntax and = interpretations in the implementations are different enough to prevent = developers from reusing code and skills when moving from product to = product. >>>>>> =E2=80=A2 I asked several individuals from key products and = services to share with me concrete examples of their JWT access tokens = (THANK YOU Dominick Baier (IdentityServer), Brian Campbell = (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for = the tokens and explanations!). >>>>>> I studied and compared all those instances, identifying = commonalities and differences. >>>>>> =E2=80=A2 I put together a presentation summarizing my findings = and suggesting a rough interoperable profile (slides: = https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt= _profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. = Thx Filip! >>>>>> =E2=80=A2 The presentation was followed up by 1.5 hours of = unconference discussion, which was incredibly valuable to get tight-loop = feedback and incorporate new ideas. John Bradley, Brian Campbell = Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig = were all there and contributed generously to the discussion. Thank = you!!! >>>>>> Note: if you were at OSW2019, participated in the discussion and = didn't get credited in the draft, my apologies: please send me a note = and I'll make things right at the next update. >>>>>> =E2=80=A2 On my flight back I did my best to incorporate all the = ideas and feedback in a draft, which will be discussed at IETF104 = tomorrow. Rifaat, Hannes and above all Brian were all super helpful in = negotiating the mysterious syntax of the RFC format and submission = process. >>>>>> I was blown away by the availability, involvement and willingness = to invest time to get things right that everyone demonstrated in the = process. This is an amazing community. >>>>>> V. >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> -- >>>> hans.zandbelt@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>=20 >>>=20 >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > -- > Vennlig hilsen >=20 > Steinar Noem > Partner Udelt AS > Systemutvikler >=20 > | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Martin Schanzenbach Fraunhofer AISEC Department Service & Application Security Parkring 4, 85748 Garching near Munich (Germany) Tel: +49 89 3229986-193 martin.schanzenbach@aisec.fraunhofer.de GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 --Apple-Mail=_EE9EA122-30F9-4B7E-B30C-B54FD5C5FBB8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEZmUgHqklfMaP3nfohDNRMeo9q/AFAlyaWqgACgkQhDNRMeo9 q/ClpxAAiMUZ79gZ09U+/6OouDV3nssqgmuzp1BkwZS1hBe5EUZmerN6VJ87uJRg jXSujNovL8c5qChe/Do8i/AgJaUYpeeFh1Hjhz4TQfLjii8A0KxZJoEeu7NOyzUH Ya+mTRIkIrXw2RyDjGREM3aHyz4x8MjfIVKg7aH/M8NPvATgsAp7f5QeAyuNooTS gfRekn3815DSPAApDBVpPqpEGloi+EU1rd2uD7EWt7CGVcRLVh1/945f4UWMEliO TFbfYSXnVCbIYweIuMVW3ziGPRY8fEK9soIZSWEDP466V/36gyySY2lDQ0/CKBl3 sH+qrZb1ejDY7svyW0JVQG48gcay35H9+YXCbU8p0goFQj37Go4rM3Ni62kXHn+x 0d09LmhHfubb4A4vDRWwkK0Pw+YgQ2EG9+V67ngMcUpYIn8kbsXTZ2EWZiJxj4x8 b2dr4aYFWza2D9zBvoRzYtdGFl2w6boGBQec3peBqXlybtMVQPEg9OrRiraGopct Zr6vHtNekZomjJHhSpI6aCB9iwmq3KchO36AGeLbUxt2KRYgNiCGrSTXH3H9Bz8p FaP7Oh+uEf5xqdKlVnYjFYJL4vnZoTo66qOXMAgltO5H1wu/GjR6lsjEzC2vT4Cl 2Wmm7KvXoPPNtTP3t6pe4PbM6qX9M8zrXrJdWNKEpXv/ZOEsKEQ= =N++l -----END PGP SIGNATURE----- --Apple-Mail=_EE9EA122-30F9-4B7E-B30C-B54FD5C5FBB8-- From nobody Tue Mar 26 11:23:38 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCFA120886 for ; Tue, 26 Mar 2019 11:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 8j4yZ4lPYvuJ for ; Tue, 26 Mar 2019 11:23:22 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21E4120878 for ; Tue, 26 Mar 2019 11:23:21 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id r24so10968691ljg.3 for ; Tue, 26 Mar 2019 11:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=heY7i/foDVYiEHvHZHFFYqw2i6K9S0qrr5CSk1WvRc8=; b=kuXb+ezsM23I3jIV2yKDLNMTvOx20/tOi7QbKQQAH6blkkyBZJ1JeV0zkD89wMSMvL 3X8ZWOlP+AqttmRsjY6OvfT2pxV7S2B2F26QUPtb8dTBW+TS5CjkK5y8JcnK4PC0Ka5t DjsSKUjynP/IfEgknVuyj3GjjflAX6MQO0Jdd8WVP+ATLOK4sTnK0o+pi8uqskKYBMao DwqZI1nmE9qlgJik4D538YG8a7SvfC0wTFdDlnGb9NvxodtY0V093vRNKxCx4/lImvn0 HNoXDPDvyG50zYePyAY9WSgdY5nxfyOUnYc53eeA1qspf055rArvz5dxOnkrVgmr8yAj az8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=heY7i/foDVYiEHvHZHFFYqw2i6K9S0qrr5CSk1WvRc8=; b=JPhlH7b2AfZFNCGrsfEoxKFM8xCgYWncEHPrKqEVOEtt8yvna8CoV0Qv/JBeYBswDM atmh2c7lQGEE7gnHTaz6Q/WJWTzoXXIyA9rnGhNMzoyOW7mPJgtPdgVYsghHg3lZVob6 p6jy8llsMEfoS7nk+WcGqF9NKor+pch3mxepzL9oaFHIgPuoKeqz1ziz8esPfBwSB1q9 p0vW8tkJnT7xVkQ7CJzx8XL6L1y8GVDxQtuayOFUFVYVqvnPIlfD1e8AbPi58ZAayd+W D3KBcTJr9VyA+/EcWpgVKQGV9dtYApsbtzlVE8oAx9BBxZ41EJTNqMfG2++ZUTkorHUI fqYQ== X-Gm-Message-State: APjAAAVr8/jkO1iXyxNNGybJkCZ0Pn4meKFy6PKEzxjXBZZ3q0l9rtce 2iF5UJQbZHJoXwx6tUFlyR42LQOiPu15SA8KPm9yPw== X-Google-Smtp-Source: APXvYqxZFc+DvO78ePFJyJQYVGVchDEyPqYuA/rTx2vZPrF5rBzYuYOztYV/g2uSr9ss5oAuqd/gucBmnFnb+KufdEI= X-Received: by 2002:a2e:8247:: with SMTP id j7mr16971965ljh.44.1553624599803; Tue, 26 Mar 2019 11:23:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vittorio Bertocci Date: Tue, 26 Mar 2019 11:23:08 -0700 Message-ID: To: Dave Tonge Cc: Steinar Noem , IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000062d75f0585036a2f" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 18:23:36 -0000 --00000000000062d75f0585036a2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, either a type check or a lookup for client_id together with absence of sub are going to be new logic- the latter seems to be more economical in term of moving parts, without loss of expressive power. I am not really committed to one model or the other, I just want to capture the approach that gets the most consensus. Let's see if more people/products chime in with perspectives on this On Tue, Mar 26, 2019 at 9:57 AM Dave Tonge wrote: > Hi Vittorio > > My understanding from Rob and others is that `sub` is already used for > tokens issued via the client credentials grant (in fact looking at the > tables from your presentation, most examples used `sub` for both user > identity and client identity). Given the desire for a spec that doesn't > break existing implementations, perhaps a new claim indicating the type o= f > access token would allow for better interoperability. > > Dave > > On Tue, 26 Mar 2019 at 17:48, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > >> thank you Steinar and everyone else for the comments on this! >> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, >> Bertrand recommend using sub only for users. Martin would like to have t= he >> sub for app only flows as well. Hans is neutral. >> That does sound like the sub as user has more consensus, tho before >> changing it I'd wait for the people currently at IETF104 to have more ti= me >> to comment as well. >> Clarification. If the goal is to be able to apply the logic "if there's = a >> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the us= e >> of sub when that's not the case. Are all OK with it? >> >> Dave, the suggestion of having explicit typing for app only vs user only >> is interesting! For the purpose of putting together an interoperable >> profile, tho, I would suggest we table it for v1 in the interest of gett= ing >> to something easy to adopt (hence with small delta vs existing >> implementations) faster. >> >> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote: >> >>> Hi Vittorio, we (the national federation-gateway for the health >>> services in norway - "HelseID") think his is a really valuable initiat= ive! >>> We also agree with Dominick concerning definition of the "sub" claim. >>> >>> Steinar >>> >>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier < >>> dbaier@leastprivilege.com>: >>> >>>> From an access token consumer (aka API) developer point of view, I >>>> prefer this logic >>>> >>>> "If sub is present - client acts on behalf of a user, if not - not." >>>> >>>> Anything more complicated has a potential of going wrong. >>>> >>>> >>>> On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: >>>> >>>> Hi Vittorio, >>>> >>>> Yeah, I=E2=80=99m concerning user & client ids collision. >>>> I haven=E2=80=99t seen such implementations, but user-select username = as sub, >>>> or incremental integer as sub & client_id will be easily collide. >>>> >>>> If you can enforce collision resistant IDs between user & client >>>> instances, it=E2=80=99ll works fine. I feel its overkill though. >>>> >>>> Sent from my iPhone >>>> >>>> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote= : >>>> >>>> Hey Nov, Dominick, Hans- >>>> thanks for the comments. That was an area I was expecting to cause mor= e >>>> discussion, and I am glad we are having this opportunity to clarify. >>>> The current language in the draft traces the etymology of sub to OpenI= D >>>> Connect core, hence Dominick observation is on point. However in the >>>> description I express something in line with 7519, which was in fact m= y >>>> intent. >>>> >>>> The idea was to provide an identifier of the calling subject that is >>>> guaranteed to be present in all cases- this would allow an SDK develop= er to >>>> use the same code for things like lookups and membership checks regard= less >>>> of the nature of the caller (user in a delegated case, app in app-only >>>> grants). The information to discriminate between user and app callers = is >>>> always available in the token (say, the caller is a user if sub!=3Dcli= ent_id, >>>> where client_id is always guaranteed to be present as well) hence ther= e's >>>> no loss in expressive power, should that difference be relevant for th= e >>>> resource server. >>>> >>>> Dominick, Hans- I probably missed the security issue you guys are >>>> thinking of in this case. Of course, if this would introduce a risk I >>>> completely agree it should be changed- I'd just like to understand bet= ter >>>> the problem. Could you expand it in a scenario/use case to clarify the= risk? >>>> Nov- playing this back: is the concern that a user and a client might >>>> have the same identifier within an IDP? When using collision resistant= IDs, >>>> as it is usually the case, that seems to be a remote possibility- did = you >>>> stumble in such scenario in production? >>>> >>>> Thanks >>>> V. >>>> >>>> >>>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt < >>>> hans.zandbelt@zmartzone.eu> wrote: >>>> >>>>> I believe there are plenty of OAuth 2.0 only use cases out there... >>>>> but nevertheless I agree with the potential confusion and thus securi= ty >>>>> problems arising from that (though one may argue the semantics are th= e >>>>> same). >>>>> >>>>> Hans. >>>>> >>>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier < >>>>> dbaier@leastprivilege.com> wrote: >>>>> >>>>>> Yes I know - and I think in hindsight it was a mistake to use the >>>>>> same claim type for multiple semantics. >>>>>> >>>>>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are makin= g things more >>>>>> complicated than they need to be - in my experience almost no-one (t= hat I >>>>>> know) does OIDC only - nor OAuth only. They always combine it. >>>>>> >>>>>> In reality this leads to potential security problems - this spec has >>>>>> the potential to rectify the situation. >>>>>> >>>>>> Dominick >>>>>> >>>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ( >>>>>> hans.zandbelt@zmartzone.eu) wrote: >>>>>> >>>>>> Without agreeing or disagreeing: OIDC does not apply here since it i= s >>>>>> not OAuth and an access token is not an id_token. >>>>>> The JWT spec says in >>>>>> https://tools.ietf.org/html/rfc7519#section-4.1.2: >>>>>> >>>>>> "The "sub" (subject) claim identifies the principal that is the >>>>>> subject of the JWT. The claims in a JWT are normally statements >>>>>> about the subject. The subject value MUST either be scoped to be >>>>>> locally unique in the context of the issuer or be globally unique= . >>>>>> The processing of this claim is generally application specific" >>>>>> >>>>>> which kind of spells "client" in case of the client credentials gran= t >>>>>> but I also do worry about Resource Servers thinking/acting only in t= erms of >>>>>> users >>>>>> >>>>>> Hans. >>>>>> >>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>>>>> dbaier@leastprivilege.com> wrote: >>>>>> >>>>>>> IMHO the sub claim should always refer to the user - and nothing >>>>>>> else. >>>>>>> >>>>>>> OIDC says: >>>>>>> >>>>>>> "Subject - Identifier for the End-User at the Issuer." >>>>>>> >>>>>>> client_id should be used to identify clients. >>>>>>> >>>>>>> cheers >>>>>>> Dominick >>>>>>> >>>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote= : >>>>>>> >>>>>>> Hi Vittorio, >>>>>>> >>>>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>>>> >>>>>>> One feedback. >>>>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and >>>>>>> client, in this spec. >>>>>>> It requires those 2 types of identifiers to be unique each other in >>>>>>> the IdP context. >>>>>>> >>>>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, = so that no such >>>>>>> constraint needed. >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> nov >>>>>>> >>>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>>>>>> vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>> Dear all, >>>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 >>>>>>> access tokens. You can find it in >>>>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-= jwt/ >>>>>>> . >>>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be >>>>>>> presenting remotely). I look forward for your comments! >>>>>>> >>>>>>> Here's just a bit of backstory, in case you are interested in how >>>>>>> this doc came to be. The trajectory it followed is somewhat unusual= . >>>>>>> >>>>>>> - Despite OAuth2 not requiring any specific format for ATs, >>>>>>> through the years I have come across multiple proprietary soluti= on using >>>>>>> JWT for their access token. The intent and scenarios addressed b= y those >>>>>>> solutions are mostly the same across vendors, but the syntax and >>>>>>> interpretations in the implementations are different enough to p= revent >>>>>>> developers from reusing code and skills when moving from product= to product. >>>>>>> - I asked several individuals from key products and services to >>>>>>> share with me concrete examples of their JWT access tokens (THAN= K YOU >>>>>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>>>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens= and >>>>>>> explanations!). >>>>>>> I studied and compared all those instances, identifying >>>>>>> commonalities and differences. >>>>>>> - I put together a presentation summarizing my findings and >>>>>>> suggesting a rough interoperable profile (slides: >>>>>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertoc= ci_-_a_jwt_profile_for_ats.pptx >>>>>>> >>>>>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>>>>> - The presentation was followed up by 1.5 hours of unconference >>>>>>> discussion, which was incredibly valuable to get tight-loop feed= back and >>>>>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzh= uvinov, >>>>>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all >>>>>>> there and contributed generously to the discussion. Thank you!!! >>>>>>> Note: if you were at OSW2019, participated in the discussion and >>>>>>> didn't get credited in the draft, my apologies: please send me a= note and >>>>>>> I'll make things right at the next update. >>>>>>> - On my flight back I did my best to incorporate all the ideas >>>>>>> and feedback in a draft, which will be discussed at IETF104 tomo= rrow. >>>>>>> Rifaat, Hannes and above all Brian were all super helpful in neg= otiating >>>>>>> the mysterious syntax of the RFC format and submission process. >>>>>>> >>>>>>> I was blown away by the availability, involvement and willingness t= o >>>>>>> invest time to get things right that everyone demonstrated in the p= rocess. >>>>>>> This is an amazing community. >>>>>>> V. >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> hans.zandbelt@zmartzone.eu >>>>>> ZmartZone IAM - www.zmartzone.eu >>>>>> >>>>>> >>>>> >>>>> -- >>>>> hans.zandbelt@zmartzone.eu >>>>> ZmartZone IAM - www.zmartzone.eu >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >>> -- >>> Vennlig hilsen >>> >>> Steinar Noem >>> Partner Udelt AS >>> Systemutvikler >>> >>> | steinar@udelt.no | hei@udelt.no | +47 955 21 620 >>> | www.udelt.no | >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub= Financial > Technology is registered in England & Wales, company registration number > 06909772 . > Moneyhub Financial Technology Limited 2018 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > --00000000000062d75f0585036a2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Dave,
    either a type check or a lookup for client_id= together with absence of sub are going to be new logic- the latter seems t= o be more economical in term of moving parts, without loss of expressive po= wer.
    I am not really committed to one model or the other, I just = want to capture the approach that gets the most consensus. Let's see if= more people/products chime in with perspectives on this=C2=A0 =C2=A0
    =

    = On Tue, Mar 26, 2019 at 9:57 AM Dave Tonge <dave.tonge@momentumft.co.uk> wrote:

    My understanding from = Rob and others is that `sub` is already used for tokens issued via the clie= nt credentials grant (in fact looking at the tables from your presentation,= most examples used `sub` for both user identity and client identity). Give= n the desire for a spec that doesn't break existing implementations, pe= rhaps a new claim indicating the type of access token would allow for bette= r interoperability.

    Dave
    =
    On Tue= , 26 Mar 2019 at 17:48, Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
    thank you Steinar and everyone else for the comments on this!=
    To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,= Bertrand recommend using sub only for users. Martin would like to have the= sub for app only flows as well. Hans is neutral.
    That does sound= like the sub as user has more consensus, tho before changing it I'd wa= it for the people currently at IETF104 to have more time to comment as well= .
    Clarification. If the goal is to be able to apply the logic &qu= ot;if there's a sub, it's a user flow", we have to explicitly = disallow (MUST NOT) the use of sub when that's not the case. Are all OK= with it?

    Dave, the suggestion of having explicit = typing for app only vs user only is interesting! For the purpose of putting= together an interoperable profile, tho, I would suggest we table it for v1= in the interest of getting to something easy to adopt (hence with small de= lta vs existing implementations) faster.=C2=A0 =C2=A0 =C2=A0
    On Tue, M= ar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no> wrote:
    Hi Vittorio, we=C2=A0 (the national federation-gateway for the health services in norway - "= HelseID")=C2=A0 think his is a really valuable initiative!
    We also= agree with Dominick concerning definition of the "sub" claim.

    <mvh>Steinar</mvh>

    tir. 26. mar. 20= 19 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com>:
    From an access token consumer (aka API) de= veloper point of view, I prefer this logic

    "If sub is present - client acts on behalf of = a user, if not - not."

    Anything more complicated has a potential of going wrong.
    =

    On 26. March = 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Yeah, I=E2=80=99m concerning user & client ids collision.
    I haven=E2=80=99t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

    If you can enforce collision resistant IDs between user & client instances, it=E2=80=99ll works fine. I feel its overkill though.

    Sent from my iPhone

    On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:

    Hey Nov, Dominick, Hans-
    thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
    The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.

    The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=3Dclient_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.

    Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
    Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?

    Thanks
    V.=C2=A0


    On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
    I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).

    Hans.

    On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

    All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.

    In reality this leads to potential security problems - this spec has the potential to rectify the situation.

    Dominick

    On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) wrote:

    Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.
    "The "sub" (subject) claim identifies the princip= al that is the
    =C2=A0 =C2=A0subject of the JWT.=C2=A0 The claims in a JWT are normally statements
    =C2=A0 =C2=A0about the subject.=C2=A0 The subject value MUST either be scoped to be
    =C2=A0 =C2=A0locally unique in the context of the issuer or be globally unique.
    =C2=A0 =C2=A0The processing of this claim is generally application specific"

    which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

    Hans.
    On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
    IMHO the sub claim should always refer to the user - and nothing else.

    OIDC says:

    "Subject - Identifier for the End-User at the Issuer."

    client_id should be used to identify clients.

    cheers
    Dominick

    On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:

    Hi Vittorio,

    Thanks for the good starting point of standardizing JWT-ized AT.

    One feedback.
    The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifie= r, end-user and client, in this spec.
    It requires those 2 types of identifiers to be unique each other in the IdP context.

    I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged contex= t, so that no such constraint needed.

    thanks

    nov
    On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittori= o.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
    Dear all,
    I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in=C2=A0https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
    I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

    Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
    I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.=C2=A0
    V.
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/oauth
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --


    --
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --
    Vennlig = hilsen

    Steinar Noem
    Partner Udelt AS
    Systemutvik= ler
    =C2=A0
    |=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@ud= elt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.u= delt.no=C2=A0|=C2=A0
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth


    --
    Dave Tonge
    CTO
    3D"Mon=
    Moneyhub Fina= ncial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    <= span style=3D"font-size:11px;line-height:15.925px;color:rgb(0,164,183);font= -weight:bold">t:=C2=A0+44 (0)117 280 5120

    Moneyhub Enterprise is a trading style of Moneyhub Financial= Technology Limited which is authorised and regulated by the Financial Cond= uct Authority ("FCA").=C2=A0Moneyhub Financial Technology is ente= red on the Financial Services Register=C2=A0(FRN=C2=A0809360) at fca.org.uk/register. Moneyhub=C2=A0Financial Technology is re= gistered in England & Wales, company registration number=C2=A0=C2=A0<= span style=3D"font-weight:bold;color:rgb(0,164,183);font-family:lato,"= open sans",arial,sans-serif;background-color:transparent;font-size:0.7= 5em">06909772=C2=A0.
    Moneyh= ub=C2= =A0Financial Technology Limited 2018=C2=A0=C2=A9

    DISCLAIMER: This email (including any at= tachments) is subject to copyright, and the information in it is confidenti= al. Use of this email or of any information in it other than by the address= ee is unauthorised and unlawful. Whilst reasonable efforts are made to ensu= re that any attachments are virus-free, it is the recipient's sole resp= onsibility to scan all attachments for viruses. All calls and emails to and= from this company may be monitored and recorded for legitimate purposes re= lating to this company's business. Any opinions expressed in this email= (or in any attachments) are those of the author and do not necessarily rep= resent the opinions of Moneyhub Financial Technology Limited or of any othe= r group company.
    --00000000000062d75f0585036a2f-- From nobody Tue Mar 26 11:33:54 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039D11208C5 for ; Tue, 26 Mar 2019 11:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 cSM-zDLdx2MA for ; Tue, 26 Mar 2019 11:33:38 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D6A1208C2 for ; Tue, 26 Mar 2019 11:33:37 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id a6so9458851lfl.5 for ; Tue, 26 Mar 2019 11:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7B6PgRvuMu5I3VCWnkOqfdTeBbkRIXpYuxK4I+XAnB4=; b=nJw/TtioJUM+L+1uOjtyQ82cNJOrCptqFaL3yx5b2bDmGYgl+DKX/9dtQhd0TzLfZ9 c5fDe7goZg6AiIYvF42sVggKCC3K70kCBWW/Y9jfNUOEX1R/QPDZ/DxXM6DvvAMEKlX7 g9/X2tYoSO8cf7LAkvVl4IVdJHMD6j/4SJBbDru0W/x8pbOoppZRwsF+DeTbd7zV3CZ8 5Jmv7/Rgwkb9g9N3V9VTgN6vxlNvaRRJkvaeihP/FP+XvoxJjUARSApp4h/tL5VrTldN D7UaaAFZIQf4wG53TpKgqcYZADbZk7fWhCOr2FtG0wZ2DKxsZ4iyvSyVfA0vw/gknpwb 6+vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7B6PgRvuMu5I3VCWnkOqfdTeBbkRIXpYuxK4I+XAnB4=; b=VUb9Pgytfnv5NcGXR+sPuSZiHVbd9fG7oixGKpF2ij8V53XNkH1Z/x6Lq5gBYw6AFQ w1pDyHOca8wF9w6iKPK2T7Mp4kNh4b0y+YJjMJe8LOrAwurpgog2Qw5JUz12TVPM+NF4 CXxfDyI/U9ca2DrkVgfNf+mEPhJQf4pHiRY1TDEG5oEsAqulVdwPDkCsU0LnVrrDLqHU vQNDyZ0SHT5gG4oc+gdqzT2v1+8wsGdngsbv5ctUiiszDAq2k/KZAh4BJVenKcBbbpxm 1U8fpQqw7MI44Zc0uxw34qFz8AUwKYOEQq1rfTi6hPQGQ+uRoi93JkzATfaCU5mkm6oj Pl5A== X-Gm-Message-State: APjAAAUE3Ei6dz4Ak+W5DdCfgcCDFHFGwMy2q0K5Z/MOVsqCdiQHypDg 1oyxw2v4+oXTR7T/lI+JEg+E1qY3lUW/GAqOEUvLvA== X-Google-Smtp-Source: APXvYqwXOHHGBi9NfnjVvzDrR9t3YJaM0Ss3IYG8lnzqRPJAWr+n2ZHv6evqKs/U8C7BZiNh3PIRIdD5Ys799NK/as8= X-Received: by 2002:a19:c005:: with SMTP id q5mr16268483lff.96.1553625215284; Tue, 26 Mar 2019 11:33:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vittorio Bertocci Date: Tue, 26 Mar 2019 11:33:24 -0700 Message-ID: To: "Schanzenbach, Martin" Cc: Steinar Noem , IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000001284680585038fe1" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 18:33:53 -0000 --0000000000001284680585038fe1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, Martin! RFC7523 was the reason for which i had the sub in the first JWT AT profile draft the way I did. The proposal of requiring it only for user flows and disallowing it otherwise is not in alignment with RFC7523, which does not sound like a good thing, but ultimately the function of JWT as assertion isn't the same as the function of an AT, and might even prevent an AT to be used for that purpose (tho I know that's what some ASes do today. Ultimately I'd like this profile to reflect the desires of as many ASes as possible, and if in-market usage differs, as long as there's no direct violation of existing specs (doesn't seem to be the case here given tha assertion!=3DAT) and there are no security/privacy issues coming with that,= I won't push back On Tue, Mar 26, 2019 at 10:00 AM Schanzenbach, Martin < martin.schanzenbach@aisec.fraunhofer.de> wrote: > > > > On 26. Mar 2019, at 17:48, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > > > thank you Steinar and everyone else for the comments on this! > > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, > Bertrand recommend using sub only for users. Martin would like to have th= e > sub for app only flows as well. Hans is neutral. > > I am also neutral to this change in general. I was just noting that in > RFC7523 in combination with client credentials + JWT bearer token grant, > the JWT MUST contain a "sub" claim with the client_id. > > So, imo it is a little inconsistent if the JWT access token does not > contain a "sub" claim with client ID when it contains claims for the clie= nt > (as there is no user context). > Hans also pointed out the JWT spec which supports this logic. > > In other words, if you think that the use of "sub" is consistent across > RFC7523 and your draft, it is fine with me and we will adopt our use > accordingly eventually. > > > That does sound like the sub as user has more consensus, tho before > changing it I'd wait for the people currently at IETF104 to have more tim= e > to comment as well. > > Clarification. If the goal is to be able to apply the logic "if there's > a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the u= se > of sub when that's not the case. Are all OK with it? > > > > Dave, the suggestion of having explicit typing for app only vs user onl= y > is interesting! For the purpose of putting together an interoperable > profile, tho, I would suggest we table it for v1 in the interest of getti= ng > to something easy to adopt (hence with small delta vs existing > implementations) faster. > > > > On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem wrote: > > Hi Vittorio, we (the national federation-gateway for the health > services in norway - "HelseID") think his is a really valuable initiativ= e! > > We also agree with Dominick concerning definition of the "sub" claim. > > > > Steinar > > > > tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier < > dbaier@leastprivilege.com>: > > From an access token consumer (aka API) developer point of view, I > prefer this logic > > > > "If sub is present - client acts on behalf of a user, if not - not." > > > > Anything more complicated has a potential of going wrong. > > > > > > On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: > > > >> Hi Vittorio, > >> > >> Yeah, I=E2=80=99m concerning user & client ids collision. > >> I haven=E2=80=99t seen such implementations, but user-select username = as sub, > or incremental integer as sub & client_id will be easily collide. > >> > >> If you can enforce collision resistant IDs between user & client > instances, it=E2=80=99ll works fine. I feel its overkill though. > >> > >> Sent from my iPhone > >> > >> On Mar 26, 2019, at 8:51, Vittorio Bertocci wrote= : > >> > >>> Hey Nov, Dominick, Hans- > >>> thanks for the comments. That was an area I was expecting to cause > more discussion, and I am glad we are having this opportunity to clarify. > >>> The current language in the draft traces the etymology of sub to > OpenID Connect core, hence Dominick observation is on point. However in t= he > description I express something in line with 7519, which was in fact my > intent. > >>> > >>> The idea was to provide an identifier of the calling subject that is > guaranteed to be present in all cases- this would allow an SDK developer = to > use the same code for things like lookups and membership checks regardles= s > of the nature of the caller (user in a delegated case, app in app-only > grants). The information to discriminate between user and app callers is > always available in the token (say, the caller is a user if sub!=3Dclient= _id, > where client_id is always guaranteed to be present as well) hence there's > no loss in expressive power, should that difference be relevant for the > resource server. > >>> > >>> Dominick, Hans- I probably missed the security issue you guys are > thinking of in this case. Of course, if this would introduce a risk I > completely agree it should be changed- I'd just like to understand better > the problem. Could you expand it in a scenario/use case to clarify the ri= sk? > >>> Nov- playing this back: is the concern that a user and a client might > have the same identifier within an IDP? When using collision resistant ID= s, > as it is usually the case, that seems to be a remote possibility- did you > stumble in such scenario in production? > >>> > >>> Thanks > >>> V. > >>> > >>> > >>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt < > hans.zandbelt@zmartzone.eu> wrote: > >>> I believe there are plenty of OAuth 2.0 only use cases out there... > but nevertheless I agree with the potential confusion and thus security > problems arising from that (though one may argue the semantics are the > same). > >>> > >>> Hans. > >>> > >>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier < > dbaier@leastprivilege.com> wrote: > >>> Yes I know - and I think in hindsight it was a mistake to use the sam= e > claim type for multiple semantics. > >>> > >>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are making= things more > complicated than they need to be - in my experience almost no-one (that I > know) does OIDC only - nor OAuth only. They always combine it. > >>> > >>> In reality this leads to potential security problems - this spec has > the potential to rectify the situation. > >>> > >>> Dominick > >>> > >>> On 25. March 2019 at 14:58:56, Hans Zandbelt ( > hans.zandbelt@zmartzone.eu) wrote: > >>> > >>>> Without agreeing or disagreeing: OIDC does not apply here since it i= s > not OAuth and an access token is not an id_token. > >>>> The JWT spec says in > https://tools.ietf.org/html/rfc7519#section-4.1.2: > >>>> > >>>> "The "sub" (subject) claim identifies the principal that is the > >>>> subject of the JWT. The claims in a JWT are normally statements > >>>> about the subject. The subject value MUST either be scoped to be > >>>> locally unique in the context of the issuer or be globally unique= . > >>>> The processing of this claim is generally application specific" > >>>> > >>>> which kind of spells "client" in case of the client credentials gran= t > but I also do worry about Resource Servers thinking/acting only in terms = of > users > >>>> > >>>> Hans. > >>>> > >>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < > dbaier@leastprivilege.com> wrote: > >>>> IMHO the sub claim should always refer to the user - and nothing els= e. > >>>> > >>>> OIDC says: > >>>> > >>>> "Subject - Identifier for the End-User at the Issuer." > >>>> > >>>> client_id should be used to identify clients. > >>>> > >>>> cheers > >>>> Dominick > >>>> > >>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: > >>>> > >>>>> Hi Vittorio, > >>>>> > >>>>> Thanks for the good starting point of standardizing JWT-ized AT. > >>>>> > >>>>> One feedback. > >>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of identifier, = end-user and > client, in this spec. > >>>>> It requires those 2 types of identifiers to be unique each other in > the IdP context. > >>>>> > >>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-legged context, = so that no such > constraint needed. > >>>>> > >>>>> thanks > >>>>> > >>>>> nov > >>>>> > >>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > >>>>>> > >>>>>> Dear all, > >>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 > access tokens. You can find it in > https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. > >>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be > presenting remotely). I look forward for your comments! > >>>>>> > >>>>>> Here's just a bit of backstory, in case you are interested in how > this doc came to be. The trajectory it followed is somewhat unusual. > >>>>>> =E2=80=A2 Despite OAuth2 not requiring any specific format for AT= s, > through the years I have come across multiple proprietary solution using > JWT for their access token. The intent and scenarios addressed by those > solutions are mostly the same across vendors, but the syntax and > interpretations in the implementations are different enough to prevent > developers from reusing code and skills when moving from product to produ= ct. > >>>>>> =E2=80=A2 I asked several individuals from key products and servi= ces to > share with me concrete examples of their JWT access tokens (THANK YOU > Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel > Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and > explanations!). > >>>>>> I studied and compared all those instances, identifying > commonalities and differences. > >>>>>> =E2=80=A2 I put together a presentation summarizing my findings a= nd > suggesting a rough interoperable profile (slides: > https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jw= t_profile_for_ats.pptx > ) - got early feedback from Filip Skokan on it. Thx Filip! > >>>>>> =E2=80=A2 The presentation was followed up by 1.5 hours of unconf= erence > discussion, which was incredibly valuable to get tight-loop feedback and > incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, > Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and > contributed generously to the discussion. Thank you!!! > >>>>>> Note: if you were at OSW2019, participated in the discussion and > didn't get credited in the draft, my apologies: please send me a note and > I'll make things right at the next update. > >>>>>> =E2=80=A2 On my flight back I did my best to incorporate all the = ideas and > feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, > Hannes and above all Brian were all super helpful in negotiating the > mysterious syntax of the RFC format and submission process. > >>>>>> I was blown away by the availability, involvement and willingness > to invest time to get things right that everyone demonstrated in the > process. This is an amazing community. > >>>>>> V. > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>>> > >>>> -- > >>>> hans.zandbelt@zmartzone.eu > >>>> ZmartZone IAM - www.zmartzone.eu > >>> > >>> > >>> -- > >>> hans.zandbelt@zmartzone.eu > >>> ZmartZone IAM - www.zmartzone.eu > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > Vennlig hilsen > > > > Steinar Noem > > Partner Udelt AS > > Systemutvikler > > > > | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > Martin Schanzenbach > Fraunhofer AISEC > Department Service & Application Security > Parkring 4, 85748 Garching near Munich (Germany) > Tel: +49 89 3229986-193 > martin.schanzenbach@aisec.fraunhofer.de > GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 > > --0000000000001284680585038fe1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thank you, Martin! RFC7523 was the reason for which i had = the sub in the first JWT AT profile draft the way I did. The proposal of re= quiring it only for user flows and disallowing it otherwise is not in align= ment with RFC7523, which does not sound like a good thing, but ultimately t= he function of JWT as assertion isn't the same as the function of an AT= , and might even prevent an AT to be used for that purpose (tho I know that= 's what some ASes do today.
    Ultimately I'd like this profile to= reflect the desires of as many ASes as possible, and if in-market usage di= ffers, as long as there's no direct violation of existing specs (doesn&= #39;t seem to be the case here given tha assertion!=3DAT) and there are no = security/privacy issues coming with that, I won't push back=C2=A0
    =

    = On Tue, Mar 26, 2019 at 10:00 AM Schanzenbach, Martin <martin.schanzenbach@aisec.fraunho= fer.de> wrote:


    > On 26. Mar 2019, at 17:48, Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.iet= f.org> wrote:
    >
    > thank you Steinar and everyone else for the comments on this!
    > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,= Bertrand recommend using sub only for users. Martin would like to have the= sub for app only flows as well. Hans is neutral.

    I am also neutral to this change in general. I was just noting that in RFC7= 523 in combination with client credentials + JWT bearer token grant, the JW= T MUST contain a "sub" claim with the client_id.

    So, imo it is a little inconsistent if the JWT access token does not contai= n a "sub" claim with client ID when it contains claims for the cl= ient (as there is no user context).
    Hans also pointed out the JWT spec which supports this logic.

    In other words, if you think that the use of "sub" is consistent = across RFC7523 and your draft, it is fine with me and we will adopt our use= accordingly eventually.

    > That does sound like the sub as user has more consensus, tho before ch= anging it I'd wait for the people currently at IETF104 to have more tim= e to comment as well.
    > Clarification. If the goal is to be able to apply the logic "if t= here's a sub, it's a user flow", we have to explicitly disallo= w (MUST NOT) the use of sub when that's not the case. Are all OK with i= t?
    >
    > Dave, the suggestion of having explicit typing for app only vs user on= ly is interesting! For the purpose of putting together an interoperable pro= file, tho, I would suggest we table it for v1 in the interest of getting to= something easy to adopt (hence with small delta vs existing implementation= s) faster.
    >
    > On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <steinar@udelt.no> wrote:
    > Hi Vittorio, we=C2=A0 (the national federation-gateway for the health = services in norway - "HelseID")=C2=A0 think his is a really valua= ble initiative!
    > We also agree with Dominick concerning definition of the "sub&quo= t; claim.
    >
    > <mvh>Steinar</mvh>
    >
    > tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com>:
    > From an access token consumer (aka API) developer point of view, I pre= fer this logic
    >
    > "If sub is present - client acts on behalf of a user, if not - no= t."
    >
    > Anything more complicated has a potential of going wrong.
    >
    >
    > On 26. March 2019 at 01:34:53, Nov Matake (    matake@gmail.com) wrote:
    >
    >> Hi Vittorio,
    >>
    >> Yeah, I=E2=80=99m concerning user & client ids collision.
    >> I haven=E2=80=99t seen such implementations, but user-select usern= ame as sub, or incremental integer as sub & client_id will be easily co= llide.
    >>
    >> If you can enforce collision resistant IDs between user & clie= nt instances, it=E2=80=99ll works fine. I feel its overkill though.
    >>
    >> Sent from my iPhone
    >>
    >> On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote:
    >>
    >>> Hey Nov, Dominick, Hans-
    >>> thanks for the comments. That was an area I was expecting to c= ause more discussion, and I am glad we are having this opportunity to clari= fy.
    >>> The current language in the draft traces the etymology of sub = to OpenID Connect core, hence Dominick observation is on point. However in = the description I express something in line with 7519, which was in fact my= intent.
    >>>
    >>> The idea was to provide an identifier of the calling subject t= hat is guaranteed to be present in all cases- this would allow an SDK devel= oper to use the same code for things like lookups and membership checks reg= ardless of the nature of the caller (user in a delegated case, app in app-o= nly grants). The information to discriminate between user and app callers i= s always available in the token (say, the caller is a user if sub!=3Dclient= _id, where client_id is always guaranteed to be present as well) hence ther= e's no loss in expressive power, should that difference be relevant for= the resource server.
    >>>
    >>> Dominick, Hans- I probably missed the security issue you guys = are thinking of in this case. Of course, if this would introduce a risk I c= ompletely agree it should be changed- I'd just like to understand bette= r the problem. Could you expand it in a scenario/use case to clarify the ri= sk?
    >>> Nov- playing this back: is the concern that a user and a clien= t might have the same identifier within an IDP? When using collision resist= ant IDs, as it is usually the case, that seems to be a remote possibility- = did you stumble in such scenario in production?
    >>>
    >>> Thanks
    >>> V.
    >>>
    >>>
    >>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone= .eu> wrote:
    >>> I believe there are plenty of OAuth 2.0 only use cases out the= re... but nevertheless I agree with the potential confusion and thus securi= ty problems arising from that (though one may argue the semantics are the s= ame).
    >>>
    >>> Hans.
    >>>
    >>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.c= om> wrote:
    >>> Yes I know - and I think in hindsight it was a mistake to use = the same claim type for multiple semantics.
    >>>
    >>> All the =E2=80=9Cthis is OIDC not OAuth=E2=80=9D arguments are= making things more complicated than they need to be - in my experience alm= ost no-one (that I know) does OIDC only - nor OAuth only. They always combi= ne it.
    >>>
    >>> In reality this leads to potential security problems - this sp= ec has the potential to rectify the situation.
    >>>
    >>> Dominick
    >>>
    >>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu<= /a>) wrote:
    >>>
    >>>> Without agreeing or disagreeing: OIDC does not apply here = since it is not OAuth and an access token is not an id_token.
    >>>> The JWT spec says in     https://tools= .ietf.org/html/rfc7519#section-4.1.2:
    >>>>
    >>>> "The "sub" (subject) claim identifies the p= rincipal that is the
    >>>>=C2=A0 =C2=A0 subject of the JWT.=C2=A0 The claims in a JWT= are normally statements
    >>>>=C2=A0 =C2=A0 about the subject.=C2=A0 The subject value MU= ST either be scoped to be
    >>>>=C2=A0 =C2=A0 locally unique in the context of the issuer o= r be globally unique.
    >>>>=C2=A0 =C2=A0 The processing of this claim is generally app= lication specific"
    >>>>
    >>>> which kind of spells "client" in case of the cli= ent credentials grant but I also do worry about Resource Servers thinking/a= cting only in terms of users
    >>>>
    >>>> Hans.
    >>>>
    >>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <dbaier@leastprivile= ge.com> wrote:
    >>>> IMHO the sub claim should always refer to the user - and n= othing else.
    >>>>
    >>>> OIDC says:
    >>>>
    >>>> "Subject - Identifier for the End-User at the Issuer.= "
    >>>>
    >>>> client_id should be used to identify clients.
    >>>>
    >>>> cheers
    >>>> Dominick
    >>>>
    >>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote:
    >>>>
    >>>>> Hi Vittorio,
    >>>>>
    >>>>> Thanks for the good starting point of standardizing JW= T-ized AT.
    >>>>>
    >>>>> One feedback.
    >>>>> The =E2=80=9Csub=E2=80=9D claim can include 2 types of= identifier, end-user and client, in this spec.
    >>>>> It requires those 2 types of identifiers to be unique = each other in the IdP context.
    >>>>>
    >>>>> I prefer omitting =E2=80=9Csub=E2=80=9D claim in 2-leg= ged context, so that no such constraint needed.
    >>>>>
    >>>>> thanks
    >>>>>
    >>>>> nov
    >>>>>
    >>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci <vi= ttorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
    >>>>>>
    >>>>>> Dear all,
    >>>>>> I just submitted a draft describing a JWT profile = for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-ac= cess-token-jwt/.
    >>>>>> I have a slot to discuss this tomorrow at IETF 104= (I'll be presenting remotely). I look forward for your comments!
    >>>>>>
    >>>>>> Here's just a bit of backstory, in case you ar= e interested in how this doc came to be. The trajectory it followed is some= what unusual.
    >>>>>>=C2=A0 =E2=80=A2 Despite OAuth2 not requiring any s= pecific format for ATs, through the years I have come across multiple propr= ietary solution using JWT for their access token. The intent and scenarios = addressed by those solutions are mostly the same across vendors, but the sy= ntax and interpretations in the implementations are different enough to pre= vent developers from reusing code and skills when moving from product to pr= oduct.
    >>>>>>=C2=A0 =E2=80=A2 I asked several individuals from k= ey products and services to share with me concrete examples of their JWT ac= cess tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (Pin= gIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the token= s and explanations!).
    >>>>>> I studied and compared all those instances, identi= fying commonalities and differences.
    >>>>>>=C2=A0 =E2=80=A2 I put together a presentation summ= arizing my findings and suggesting a rough interoperable profile (slides: <= a href=3D"https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocc= i_-_a_jwt_profile_for_ats.pptx" rel=3D"noreferrer" target=3D"_blank">https:= //sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profil= e_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Fili= p!
    >>>>>>=C2=A0 =E2=80=A2 The presentation was followed up b= y 1.5 hours of unconference discussion, which was incredibly valuable to ge= t tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbe= ll Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig= were all there and contributed generously to the discussion. Thank you!!!<= br> >>>>>> Note: if you were at OSW2019, participated in the = discussion and didn't get credited in the draft, my apologies: please s= end me a note and I'll make things right at the next update.
    >>>>>>=C2=A0 =E2=80=A2 On my flight back I did my best to= incorporate all the ideas and feedback in a draft, which will be discussed= at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super hel= pful in negotiating the mysterious syntax of the RFC format and submission = process.
    >>>>>> I was blown away by the availability, involvement = and willingness to invest time to get things right that everyone demonstrat= ed in the process. This is an amazing community.
    >>>>>> V.
    >>>>>> _______________________________________________ >>>>>> OAuth mailing list
    >>>>>> OAuth@ietf.org
    >>>>>> https://www.ietf.org/mailman/lis= tinfo/oauth
    >>>>>
    >>>>> _______________________________________________
    >>>>> OAuth mailing list
    >>>>> OA= uth@ietf.org
    >>>>> https://www.ietf.org/mailman/listinf= o/oauth
    >>>> _______________________________________________
    >>>> OAuth mailing list
    >>>> OAuth@= ietf.org
    >>>> https://www.ietf.org/mailman/listinfo/oa= uth
    >>>>
    >>>>
    >>>> --
    >>>> hans.zandbelt@zmartzone.eu
    >>>> ZmartZone IAM - www.zmartzone.eu
    >>>
    >>>
    >>> --
    >>> hans.zandbelt@zmartzone.eu
    >>> ZmartZone IAM - www.zmartzone.eu
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org=
    > https://www.ietf.org/mailman/listinfo/oauth
    >
    >
    > --
    > Vennlig hilsen
    >
    > Steinar Noem
    > Partner Udelt AS
    > Systemutvikler
    >
    > | steinar@udelt.= no | hei@udelt.no= =C2=A0 | +47 955 21 620 | www.udelt.no |
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org=
    > https://www.ietf.org/mailman/listinfo/oauth


    Martin Schanzenbach
    Fraunhofer AISEC
    Department Service & Application Security
    Parkring 4, 85748 Garching near Munich (Germany)
    Tel: +49 89 3229986-193
    martin.schanzenbach@aisec.fraunhofer.de
    GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0

    --0000000000001284680585038fe1-- From nobody Tue Mar 26 14:18:07 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9323112006D for ; Tue, 26 Mar 2019 14:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=difidrift.onmicrosoft.com 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 TvHy5Gzht7r3 for ; Tue, 26 Mar 2019 14:18:02 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on062e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F61A120020 for ; Tue, 26 Mar 2019 14:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=difidrift.onmicrosoft.com; s=selector1-difi-no; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ER5sYClXwZPruCqtmSAvQP30uR61dC9B23nPLE84GHc=; b=M1XlXr+XS5Ci/vI7EozJEgFXRcPAvFsy8J0SN6a5LFXg36Wra45A3q4UYxXq1Exth5HZZbkdhCoPr85qWdWuHrZ0mS3XaC7dIy327VZovHVM6eCLNlu1NFMxTub89LC0+A2516G43AmzaXUmGQ5dny0Ekz29ZVzCLTUtX+0o2Fw= Received: from HE1PR0102MB2585.eurprd01.prod.exchangelabs.com (10.170.251.138) by HE1PR0102MB3196.eurprd01.prod.exchangelabs.com (10.167.124.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Tue, 26 Mar 2019 21:17:58 +0000 Received: from HE1PR0102MB2585.eurprd01.prod.exchangelabs.com ([fe80::bc28:a6c2:2867:f6d]) by HE1PR0102MB2585.eurprd01.prod.exchangelabs.com ([fe80::bc28:a6c2:2867:f6d%4]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 21:17:58 +0000 From: =?utf-8?B?QmlubmluZ3Niw7gsIErDuHJnZW4=?= To: IETF oauth WG Thread-Topic: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 Thread-Index: AdTkGV7xrBlf0o/9RSifvzG0j09NKw== Date: Tue, 26 Mar 2019 21:17:58 +0000 Message-ID: Accept-Language: nb-NO, en-US Content-Language: nb-NO X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jorgen.Binningsbo@difi.no; x-originating-ip: [217.17.216.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7d0288c1-bcef-4818-a33c-08d6b2308566 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0102MB3196; x-ms-traffictypediagnostic: HE1PR0102MB3196: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(396003)(39850400004)(136003)(189003)(199004)(51914003)(52314003)(66066001)(53546011)(81166006)(790700001)(68736007)(6506007)(7736002)(66574012)(97736004)(6116002)(74482002)(3846002)(72206003)(8936002)(81156014)(478600001)(33656002)(102836004)(85182001)(8676002)(26005)(316002)(54896002)(236005)(6916009)(6306002)(966005)(6436002)(256004)(53946003)(7696005)(186003)(9686003)(45080400002)(53936002)(476003)(55016002)(71190400001)(486006)(71200400001)(229853002)(52536014)(606006)(74316002)(106356001)(85202003)(2906002)(517774005)(53386004)(5660300002)(86362001)(105586002)(30864003)(99286004)(14454004)(5070765005)(14444005)(25786009)(6246003)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0102MB3196; H:HE1PR0102MB2585.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: difi.no does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BQPKw8j+6uf4geDAjFbZSrERMqe1yj8hHvqPZmkPD9jespi3duHZSVEjze4e/8dCffDdRTYP62kOsQS5YsEcJdm2HGWjPeO/8OqTALGLmx3lDV/APaPwogtwgbKHEIjEDf71ocSs4R7O7FRhP8F2v9johF91I8c4uEeK73z0rUb5HGi99fLkVztpzkEg9L+gOK27KhXHkREDyEdFJMK/90QFhR6e5RpjmCSQlpGzLUovDa+o7HRYC5GbR1tF143IF+zsrF5yXH50Tfvmvh8FLpKARdG7qRpRgvEUALaqYRjBLAb3q6xddnNI9y2Ad44BYwtT7c7VwxN+ovaGkUtXKRGyPZiEzBATwcIsVC6iUJJu0UY8tGymiu5u25ysthHByoJpt1b46HEySM1nKMjTBCAyFcZO4NzIQNERkH+sVZk= Content-Type: multipart/alternative; boundary="_000_HE1PR0102MB25855DAD2D8674E96AD4118DF75F0HE1PR0102MB2585_" MIME-Version: 1.0 X-OriginatorOrg: difi.no X-MS-Exchange-CrossTenant-Network-Message-Id: 7d0288c1-bcef-4818-a33c-08d6b2308566 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 21:17:58.4183 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 250f5e75-599c-4614-9707-0ced6114ffc6 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0102MB3196 Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 21:18:06 -0000 --_000_HE1PR0102MB25855DAD2D8674E96AD4118DF75F0HE1PR0102MB2585_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQpXZSBoYXZlIGEgbWFjaGluZS10by1tYWNoaW5lIHNjZW5hcmlvIHdoZXJlIGNs aWVudHMsIFJTZXMgYW5kIG91ciBBUyBhbGwgYmVsb25nIHRvIGRpZmZlcmVudCBsZWdhbCBlbnRp dGllcy4NCg0KDQoNClNvbWUgUlNlcyByZXF1aXJlIHRoZWlyIGNsaWVudHMgdG8gbGltaXQgdGhl IGFjY2VzcyB0b2tlbiB0byBhIHNwZWNpZmljIFJlc291cmNlIE93bmVyLCB3aGlsZSBvdGhlciBS U2VzIGRvbid0LiBJbiB0aGUgZm9ybWVyIGNhc2UsIHdlIHVzZSAnc3ViJyB0byBpZGVudGlmeSB0 aGF0IFJlc291cmNlIE93bmVyLiAgSW4gc3VjaCBhIG1peGVkIGRlcGxveW1lbnQgc2NlbmFyaW8s IGFsbG93aW5nIHVzaW5nICdzdWInIGZvciBkaWZmZXJlbnQgbWVhbmluZ3MgY2FuIGxlYWQgdG8g Y29uZnVzaW9uLCBzbyBJIHRoaW5rIHRoZSBhY3R1YWwgbWVhbmluZyBzaG91bGQgYmUgZXhwbGlj aXRseSBzaWduYWxsZWQgbGlrZSBEYXZlIHN1Z2dlc3RzIGJlbG93Lg0KDQoNCg0KSGF2aW5nIHNh aWQgdGhhdCwgSSBkbyBwcmVmZXIgdG8gbGltaXQgdGhlIHVzYWdlIG9mICdzdWInIGluIGFjY2Vz cyB0b2tlbnMgZm9yIHRoZSBFbmQgVXNlciBvbmx5Lg0KDQoNCg0KDQoNCkFzIGEgc2lkZSBub3Rl LCBpbiBvdXIgY2FzZSB3ZSBuZWVkIGEgbW9yZSBmb3JtYWwgY2xpZW50IGlkZW50aWZpY2F0aW9u IHRoYW4gdGhlIGNsaWVudF9pZCBhbG9uZSAoYXMgdGhleSBhcmUgcmFuZG9tbHkgZ2VuZXJhdGVk IGJ5IERDUiksICBhbmQgaGF2ZSB0aHVzIG9wdGVkIGZvciBhIGN1c3RvbSBjbGFpbSBgY2xpZW50 X293bmVyYCBjb250YWluaW5nIHRoZSByZWdpc3RlcmVkIGNvbXBhbnkgaWRlbnRpZmllci4gIFdl IHB1bGwgdGhpcyBvdXQgZnJvbSBjZXJ0aWZpY2F0ZSB1c2VkIHRvIHNpZ24gdGhlIEpXVC1ncmFu dCAoUkZDNzUyMykgZnJvbSB0aGUgdG9rZW4gcmVxdWVzdC4gICBXZSBjb3VsZCBvZiBjb3Vyc2Ug aGF2ZSB1c2VkIOKAmHN1YuKAmSBmb3IgY2xpZW50X293bmVyLCBidXQgdGhhdCB3b3VsZCByZXF1 aXJlIHVzIHRvIGludmVudCBhbm90aGVyIGN1c3RvbSBjbGFpbSBmb3IgdGhvc2UgUlNlcyB0aGF0 IHJlcXVpcmVzIFJPLWxpbWl0ZWQgdG9rZW5zLiAgICBUbyBtYWtlIG1hdHRlcnMgZXZlbiBtb3Jl IGNvbXBsaWNhdGVkLCB0aGVyZSBtaWdodCBiZSBidXNpbmVzcyBkZWxlZ2F0aW9uIGhhcHBlbmlu ZywgIHdoZXJlIGNvbXBhbnkgQSBydW5uaW5nIHRoZSBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFs ZiBvZiBkaWZmZXJlbnQgb3RoZXIgY29tcGFuaWVzIEIsQyxE4oCmIGFuZCB0aGUgaW5zdGFudGFu ZW91cyBBK0Igb3IgQStDIHJlbGF0aW9uIGFsc28gaGF2ZSB0byBiZSBjb21tdW5pY2F0ZWQgaW4g dGhlIHRva2VuICAoQWNjb3JkaW5nIHRvIEVVIHByaXZhY3kgbGF3cywgSSBiZWxpdmUgQSBpcyB0 aGUgRGF0YSBQcm9jZXNzb3IgYW5kIHRoZWlyIGN1c3RvbWVyIEIsQyxE4oCmIGFyZSBEYXRhIENv bnRyb2xsZXIpLiAgIFNvIGFnYWluIHRoaXMgbGVhZHMgbWUgdG8gdGhpbmsgdGhhdCBjbGllbnQg aWRlbnRpZmljYXRpb24gc2hvdWxkIGJlIGtlcHQgaW4gc2VwYXJhdGUgY2xhaW1zLg0KDQoNCg0K QW55d2F5LCBmb3IgdXMgYXMgdXNlciBvZiB0aGUgb2F1dGgyIHByb3RvY29scywgdGhpcyBkcmFm dCBpcyB3ZWxjb21lICENCg0KDQoNCg0KDQpLaW5kIHJlZ2FyZHMsDQotLQ0KSsO4cmdlbiBCaW5u aW5nc2LDuA0KUHJvZHVjdCBPd25lciwgTm9yd2VnaWFuIE5hdGlvbmFsIGVJRCBJbmZyYXN0cnVj dHVyZSAoSUQtcG9ydGVuKQ0KDQoNCkZyYTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+ IFDDpSB2ZWduZSBhdiBEYXZlIFRvbmdlDQpTZW5kdDogdGlyc2RhZyAyNi4gbWFycyAyMDE5IDA5 LjI3DQpUaWw6IERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPg0KS29w aTogSUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQpFbW5lOiBSZTogW09BVVRILVdHXSBk cmFmdC1iZXJ0b2NjaS1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LTAwDQoNClRoYW5rcyBWaXR0b3Jp byBmb3IgeW91ciBwcmVzZW50YXRpb24gYW5kIHB1dHRpbmcgdGhpcyBkcmFmdCB0b2dldGhlci4N Cg0KSSBhZ3JlZSB3aXRoIERvbWluY2sgdGhhdCB0aGVyZSBpcyBhIHBvdGVudGlhbCBvZiB0aGlu Z3MgZ29pbmcgd3Jvbmcgd2hlbiBgc3ViYCBoYXMgbXVsdGlwbGUgbWVhbmluZ3MuDQpIb3dldmVy IEkgY2FuIHNlZSB0aGF0IHVzaW5nIGBzdWJgIGZvciBhIGNsaWVudF9pZCBzZW1hbnRpY2FsbHkg bWFrZXMgc2Vuc2UgaW4gc29tZSBzaXR1YXRpb25zIGFuZCBJIGFncmVlIHRoYXQgaXQgbWFrZXMg aXQgc2ltcGxlciBmcm9tIGFuIFNESyBwb2ludCBvZiB2aWV3IGZvciB0aGVyZSB0byBhbHdheXMg YmUgYSBgc3ViYC4NCg0KTXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0aGF0IGVpdGhlciB0aGVyZSBp cyBhbiBleHBsaWNpdCB0eXBlIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiAidXNlciBhY2Nlc3Mg dG9rZW5zIiBhbmQgImFwcGxpY2F0aW9uIGFjY2VzcyB0b2tlbnMiLCBvciBmYWlsaW5nIHRoYXQg dGhlIGBzdWJgIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhlIGRpZmZlcmVuY2UuDQoNCkZ1cnRoZXJt b3JlIGFuIGFncmVlbWVudCBvbiB0aGUgbmFtaW5nIGFuZCBkZXNjcmlwdGlvbiBvZiB0aGVzZSB0 d28gdHlwZXMgb2YgYWNjZXNzIHRva2VucyB3b3VsZCBiZSBoZWxwZnVsIG1vcmUgZ2VuZXJhbGx5 Lg0KDQpEYXZlDQoNCk9uIFR1ZSwgMjYgTWFyIDIwMTkgYXQgMDc6MjUsIERvbWluaWNrIEJhaWVy IDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPG1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2Uu Y29tPj4gd3JvdGU6DQpGcm9tIGFuIGFjY2VzcyB0b2tlbiBjb25zdW1lciAoYWthIEFQSSkgZGV2 ZWxvcGVyIHBvaW50IG9mIHZpZXcsIEkgcHJlZmVyIHRoaXMgbG9naWMNCg0KIklmIHN1YiBpcyBw cmVzZW50IC0gY2xpZW50IGFjdHMgb24gYmVoYWxmIG9mIGEgdXNlciwgaWYgbm90IC0gbm90LiIN Cg0KQW55dGhpbmcgbW9yZSBjb21wbGljYXRlZCBoYXMgYSBwb3RlbnRpYWwgb2YgZ29pbmcgd3Jv bmcuDQoNCg0KDQpPbiAyNi4gTWFyY2ggMjAxOSBhdCAwMTozNDo1MywgTm92IE1hdGFrZSAobWF0 YWtlQGdtYWlsLmNvbTxtYWlsdG86bWF0YWtlQGdtYWlsLmNvbT4pIHdyb3RlOg0KSGkgVml0dG9y aW8sDQoNClllYWgsIEnigJltIGNvbmNlcm5pbmcgdXNlciAmIGNsaWVudCBpZHMgY29sbGlzaW9u Lg0KSSBoYXZlbuKAmXQgc2VlbiBzdWNoIGltcGxlbWVudGF0aW9ucywgYnV0IHVzZXItc2VsZWN0 IHVzZXJuYW1lIGFzIHN1Yiwgb3IgaW5jcmVtZW50YWwgaW50ZWdlciBhcyBzdWIgJiBjbGllbnRf aWQgd2lsbCBiZSBlYXNpbHkgY29sbGlkZS4NCg0KSWYgeW91IGNhbiBlbmZvcmNlIGNvbGxpc2lv biByZXNpc3RhbnQgSURzIGJldHdlZW4gdXNlciAmIGNsaWVudCBpbnN0YW5jZXMsIGl04oCZbGwg d29ya3MgZmluZS4gSSBmZWVsIGl0cyBvdmVya2lsbCB0aG91Z2guDQoNClNlbnQgZnJvbSBteSBp UGhvbmUNCg0KT24gTWFyIDI2LCAyMDE5LCBhdCA4OjUxLCBWaXR0b3JpbyBCZXJ0b2NjaSA8Vml0 dG9yaW9AYXV0aDAuY29tPG1haWx0bzpWaXR0b3Jpb0BhdXRoMC5jb20+PiB3cm90ZToNCkhleSBO b3YsIERvbWluaWNrLCBIYW5zLQ0KdGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFRoYXQgd2FzIGFu IGFyZWEgSSB3YXMgZXhwZWN0aW5nIHRvIGNhdXNlIG1vcmUgZGlzY3Vzc2lvbiwgYW5kIEkgYW0g Z2xhZCB3ZSBhcmUgaGF2aW5nIHRoaXMgb3Bwb3J0dW5pdHkgdG8gY2xhcmlmeS4NClRoZSBjdXJy ZW50IGxhbmd1YWdlIGluIHRoZSBkcmFmdCB0cmFjZXMgdGhlIGV0eW1vbG9neSBvZiBzdWIgdG8g T3BlbklEIENvbm5lY3QgY29yZSwgaGVuY2UgRG9taW5pY2sgb2JzZXJ2YXRpb24gaXMgb24gcG9p bnQuIEhvd2V2ZXIgaW4gdGhlIGRlc2NyaXB0aW9uIEkgZXhwcmVzcyBzb21ldGhpbmcgaW4gbGlu ZSB3aXRoIDc1MTksIHdoaWNoIHdhcyBpbiBmYWN0IG15IGludGVudC4NCg0KVGhlIGlkZWEgd2Fz IHRvIHByb3ZpZGUgYW4gaWRlbnRpZmllciBvZiB0aGUgY2FsbGluZyBzdWJqZWN0IHRoYXQgaXMg Z3VhcmFudGVlZCB0byBiZSBwcmVzZW50IGluIGFsbCBjYXNlcy0gdGhpcyB3b3VsZCBhbGxvdyBh biBTREsgZGV2ZWxvcGVyIHRvIHVzZSB0aGUgc2FtZSBjb2RlIGZvciB0aGluZ3MgbGlrZSBsb29r dXBzIGFuZCBtZW1iZXJzaGlwIGNoZWNrcyByZWdhcmRsZXNzIG9mIHRoZSBuYXR1cmUgb2YgdGhl IGNhbGxlciAodXNlciBpbiBhIGRlbGVnYXRlZCBjYXNlLCBhcHAgaW4gYXBwLW9ubHkgZ3JhbnRz KS4gVGhlIGluZm9ybWF0aW9uIHRvIGRpc2NyaW1pbmF0ZSBiZXR3ZWVuIHVzZXIgYW5kIGFwcCBj YWxsZXJzIGlzIGFsd2F5cyBhdmFpbGFibGUgaW4gdGhlIHRva2VuIChzYXksIHRoZSBjYWxsZXIg aXMgYSB1c2VyIGlmIHN1YiE9Y2xpZW50X2lkLCB3aGVyZSBjbGllbnRfaWQgaXMgYWx3YXlzIGd1 YXJhbnRlZWQgdG8gYmUgcHJlc2VudCBhcyB3ZWxsKSBoZW5jZSB0aGVyZSdzIG5vIGxvc3MgaW4g ZXhwcmVzc2l2ZSBwb3dlciwgc2hvdWxkIHRoYXQgZGlmZmVyZW5jZSBiZSByZWxldmFudCBmb3Ig dGhlIHJlc291cmNlIHNlcnZlci4NCg0KRG9taW5pY2ssIEhhbnMtIEkgcHJvYmFibHkgbWlzc2Vk IHRoZSBzZWN1cml0eSBpc3N1ZSB5b3UgZ3V5cyBhcmUgdGhpbmtpbmcgb2YgaW4gdGhpcyBjYXNl LiBPZiBjb3Vyc2UsIGlmIHRoaXMgd291bGQgaW50cm9kdWNlIGEgcmlzayBJIGNvbXBsZXRlbHkg YWdyZWUgaXQgc2hvdWxkIGJlIGNoYW5nZWQtIEknZCBqdXN0IGxpa2UgdG8gdW5kZXJzdGFuZCBi ZXR0ZXIgdGhlIHByb2JsZW0uIENvdWxkIHlvdSBleHBhbmQgaXQgaW4gYSBzY2VuYXJpby91c2Ug Y2FzZSB0byBjbGFyaWZ5IHRoZSByaXNrPw0KTm92LSBwbGF5aW5nIHRoaXMgYmFjazogaXMgdGhl IGNvbmNlcm4gdGhhdCBhIHVzZXIgYW5kIGEgY2xpZW50IG1pZ2h0IGhhdmUgdGhlIHNhbWUgaWRl bnRpZmllciB3aXRoaW4gYW4gSURQPyBXaGVuIHVzaW5nIGNvbGxpc2lvbiByZXNpc3RhbnQgSURz LCBhcyBpdCBpcyB1c3VhbGx5IHRoZSBjYXNlLCB0aGF0IHNlZW1zIHRvIGJlIGEgcmVtb3RlIHBv c3NpYmlsaXR5LSBkaWQgeW91IHN0dW1ibGUgaW4gc3VjaCBzY2VuYXJpbyBpbiBwcm9kdWN0aW9u Pw0KDQpUaGFua3MNClYuDQoNCg0KT24gTW9uLCBNYXIgMjUsIDIwMTkgYXQgNzo0NCBBTSBIYW5z IFphbmRiZWx0IDxoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTxtYWlsdG86aGFucy56YW5kYmVs dEB6bWFydHpvbmUuZXU+PiB3cm90ZToNCkkgYmVsaWV2ZSB0aGVyZSBhcmUgcGxlbnR5IG9mIE9B dXRoIDIuMCBvbmx5IHVzZSBjYXNlcyBvdXQgdGhlcmUuLi4gYnV0IG5ldmVydGhlbGVzcyBJIGFn cmVlIHdpdGggdGhlIHBvdGVudGlhbCBjb25mdXNpb24gYW5kIHRodXMgc2VjdXJpdHkgcHJvYmxl bXMgYXJpc2luZyBmcm9tIHRoYXQgKHRob3VnaCBvbmUgbWF5IGFyZ3VlIHRoZSBzZW1hbnRpY3Mg YXJlIHRoZSBzYW1lKS4NCg0KSGFucy4NCg0KT24gTW9uLCBNYXIgMjUsIDIwMTkgYXQgMzozOSBQ TSBEb21pbmljayBCYWllciA8ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTxtYWlsdG86ZGJhaWVy QGxlYXN0cHJpdmlsZWdlLmNvbT4+IHdyb3RlOg0KWWVzIEkga25vdyAtIGFuZCBJIHRoaW5rIGlu IGhpbmRzaWdodCBpdCB3YXMgYSBtaXN0YWtlIHRvIHVzZSB0aGUgc2FtZSBjbGFpbSB0eXBlIGZv ciBtdWx0aXBsZSBzZW1hbnRpY3MuDQoNCkFsbCB0aGUg4oCcdGhpcyBpcyBPSURDIG5vdCBPQXV0 aOKAnSBhcmd1bWVudHMgYXJlIG1ha2luZyB0aGluZ3MgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRo ZXkgbmVlZCB0byBiZSAtIGluIG15IGV4cGVyaWVuY2UgYWxtb3N0IG5vLW9uZSAodGhhdCBJIGtu b3cpIGRvZXMgT0lEQyBvbmx5IC0gbm9yIE9BdXRoIG9ubHkuIFRoZXkgYWx3YXlzIGNvbWJpbmUg aXQuDQoNCkluIHJlYWxpdHkgdGhpcyBsZWFkcyB0byBwb3RlbnRpYWwgc2VjdXJpdHkgcHJvYmxl bXMgLSB0aGlzIHNwZWMgaGFzIHRoZSBwb3RlbnRpYWwgdG8gcmVjdGlmeSB0aGUgc2l0dWF0aW9u Lg0KDQpEb21pbmljaw0KDQoNCk9uIDI1LiBNYXJjaCAyMDE5IGF0IDE0OjU4OjU2LCBIYW5zIFph bmRiZWx0IChoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTxtYWlsdG86aGFucy56YW5kYmVsdEB6 bWFydHpvbmUuZXU+KSB3cm90ZToNCldpdGhvdXQgYWdyZWVpbmcgb3IgZGlzYWdyZWVpbmc6IE9J REMgZG9lcyBub3QgYXBwbHkgaGVyZSBzaW5jZSBpdCBpcyBub3QgT0F1dGggYW5kIGFuIGFjY2Vz cyB0b2tlbiBpcyBub3QgYW4gaWRfdG9rZW4uDQpUaGUgSldUIHNwZWMgc2F5cyBpbiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOSNzZWN0aW9uLTQuMS4yOg0KDQoiVGhlICJzdWIi IChzdWJqZWN0KSBjbGFpbSBpZGVudGlmaWVzIHRoZSBwcmluY2lwYWwgdGhhdCBpcyB0aGUNCiAg IHN1YmplY3Qgb2YgdGhlIEpXVC4gIFRoZSBjbGFpbXMgaW4gYSBKV1QgYXJlIG5vcm1hbGx5IHN0 YXRlbWVudHMNCiAgIGFib3V0IHRoZSBzdWJqZWN0LiAgVGhlIHN1YmplY3QgdmFsdWUgTVVTVCBl aXRoZXIgYmUgc2NvcGVkIHRvIGJlDQogICBsb2NhbGx5IHVuaXF1ZSBpbiB0aGUgY29udGV4dCBv ZiB0aGUgaXNzdWVyIG9yIGJlIGdsb2JhbGx5IHVuaXF1ZS4NCiAgIFRoZSBwcm9jZXNzaW5nIG9m IHRoaXMgY2xhaW0gaXMgZ2VuZXJhbGx5IGFwcGxpY2F0aW9uIHNwZWNpZmljIg0KDQp3aGljaCBr aW5kIG9mIHNwZWxscyAiY2xpZW50IiBpbiBjYXNlIG9mIHRoZSBjbGllbnQgY3JlZGVudGlhbHMg Z3JhbnQgYnV0IEkgYWxzbyBkbyB3b3JyeSBhYm91dCBSZXNvdXJjZSBTZXJ2ZXJzIHRoaW5raW5n L2FjdGluZyBvbmx5IGluIHRlcm1zIG9mIHVzZXJzDQoNCkhhbnMuDQoNCk9uIE1vbiwgTWFyIDI1 LCAyMDE5IGF0IDI6NDEgUE0gRG9taW5pY2sgQmFpZXIgPGRiYWllckBsZWFzdHByaXZpbGVnZS5j b208bWFpbHRvOmRiYWllckBsZWFzdHByaXZpbGVnZS5jb20+PiB3cm90ZToNCklNSE8gdGhlIHN1 YiBjbGFpbSBzaG91bGQgYWx3YXlzIHJlZmVyIHRvIHRoZSB1c2VyIC0gYW5kIG5vdGhpbmcgZWxz ZS4NCg0KT0lEQyBzYXlzOg0KDQoiU3ViamVjdCAtIElkZW50aWZpZXIgZm9yIHRoZSBFbmQtVXNl ciBhdCB0aGUgSXNzdWVyLiINCg0KY2xpZW50X2lkIHNob3VsZCBiZSB1c2VkIHRvIGlkZW50aWZ5 IGNsaWVudHMuDQoNCmNoZWVycw0KRG9taW5pY2sNCg0KDQpPbiAyNS4uIE1hcmNoIDIwMTkgYXQg MDU6MTM6MDMsIE5vdiBNYXRha2UgKG1hdGFrZUBnbWFpbC5jb208bWFpbHRvOm1hdGFrZUBnbWFp bC5jb20+KSB3cm90ZToNCkhpIFZpdHRvcmlvLA0KDQpUaGFua3MgZm9yIHRoZSBnb29kIHN0YXJ0 aW5nIHBvaW50IG9mIHN0YW5kYXJkaXppbmcgSldULWl6ZWQgQVQuDQoNCk9uZSBmZWVkYmFjay4N ClRoZSDigJxzdWLigJ0gY2xhaW0gY2FuIGluY2x1ZGUgMiB0eXBlcyBvZiBpZGVudGlmaWVyLCBl bmQtdXNlciBhbmQgY2xpZW50LCBpbiB0aGlzIHNwZWMuDQpJdCByZXF1aXJlcyB0aG9zZSAyIHR5 cGVzIG9mIGlkZW50aWZpZXJzIHRvIGJlIHVuaXF1ZSBlYWNoIG90aGVyIGluIHRoZSBJZFAgY29u dGV4dC4NCg0KSSBwcmVmZXIgb21pdHRpbmcg4oCcc3Vi4oCdIGNsYWltIGluIDItbGVnZ2VkIGNv bnRleHQsIHNvIHRoYXQgbm8gc3VjaCBjb25zdHJhaW50IG5lZWRlZC4NCg0KdGhhbmtzDQoNCm5v dg0KDQoNCk9uIE1hciAyNSwgMjAxOSwgYXQgODoyOSwgVml0dG9yaW8gQmVydG9jY2kgPHZpdHRv cmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzp2aXR0b3Jpby5i ZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpEZWFyIGFsbCwN CkkganVzdCBzdWJtaXR0ZWQgYSBkcmFmdCBkZXNjcmliaW5nIGEgSldUIHByb2ZpbGUgZm9yIE9B dXRoIDIuMCBhY2Nlc3MgdG9rZW5zLiBZb3UgY2FuIGZpbmQgaXQgaW4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC8u DQpJIGhhdmUgYSBzbG90IHRvIGRpc2N1c3MgdGhpcyB0b21vcnJvdyBhdCBJRVRGIDEwNCAoSSds bCBiZSBwcmVzZW50aW5nIHJlbW90ZWx5KS4gSSBsb29rIGZvcndhcmQgZm9yIHlvdXIgY29tbWVu dHMhDQoNCkhlcmUncyBqdXN0IGEgYml0IG9mIGJhY2tzdG9yeSwgaW4gY2FzZSB5b3UgYXJlIGlu dGVyZXN0ZWQgaW4gaG93IHRoaXMgZG9jIGNhbWUgdG8gYmUuIFRoZSB0cmFqZWN0b3J5IGl0IGZv bGxvd2VkIGlzIHNvbWV3aGF0IHVudXN1YWwuDQoNCiAgKiAgIERlc3BpdGUgT0F1dGgyIG5vdCBy ZXF1aXJpbmcgYW55IHNwZWNpZmljIGZvcm1hdCBmb3IgQVRzLCB0aHJvdWdoIHRoZSB5ZWFycyBJ IGhhdmUgY29tZSBhY3Jvc3MgbXVsdGlwbGUgcHJvcHJpZXRhcnkgc29sdXRpb24gdXNpbmcgSldU IGZvciB0aGVpciBhY2Nlc3MgdG9rZW4uIFRoZSBpbnRlbnQgYW5kIHNjZW5hcmlvcyBhZGRyZXNz ZWQgYnkgdGhvc2Ugc29sdXRpb25zIGFyZSBtb3N0bHkgdGhlIHNhbWUgYWNyb3NzIHZlbmRvcnMs IGJ1dCB0aGUgc3ludGF4IGFuZCBpbnRlcnByZXRhdGlvbnMgaW4gdGhlIGltcGxlbWVudGF0aW9u cyBhcmUgZGlmZmVyZW50IGVub3VnaCB0byBwcmV2ZW50IGRldmVsb3BlcnMgZnJvbSByZXVzaW5n IGNvZGUgYW5kIHNraWxscyB3aGVuIG1vdmluZyBmcm9tIHByb2R1Y3QgdG8gcHJvZHVjdC4NCiAg KiAgIEkgYXNrZWQgc2V2ZXJhbCBpbmRpdmlkdWFscyBmcm9tIGtleSBwcm9kdWN0cyBhbmQgc2Vy dmljZXMgdG8gc2hhcmUgd2l0aCBtZSBjb25jcmV0ZSBleGFtcGxlcyBvZiB0aGVpciBKV1QgYWNj ZXNzIHRva2VucyAoVEhBTksgWU9VIERvbWluaWNrIEJhaWVyIChJZGVudGl0eVNlcnZlciksIEJy aWFuIENhbXBiZWxsIChQaW5nSWRlbnRpdHkpLCBEYW5pZWwgRG9iYWxpYW4gKE1pY3Jvc29mdCks IEthcmwgR3Vpbm5lc3MgKE9rdGEpIGZvciB0aGUgdG9rZW5zIGFuZCBleHBsYW5hdGlvbnMhKS4N Ckkgc3R1ZGllZCBhbmQgY29tcGFyZWQgYWxsIHRob3NlIGluc3RhbmNlcywgaWRlbnRpZnlpbmcg Y29tbW9uYWxpdGllcyBhbmQgZGlmZmVyZW5jZXMuDQogICogICBJIHB1dCB0b2dldGhlciBhIHBy ZXNlbnRhdGlvbiBzdW1tYXJpemluZyBteSBmaW5kaW5ncyBhbmQgc3VnZ2VzdGluZyBhIHJvdWdo IGludGVyb3BlcmFibGUgcHJvZmlsZSAoc2xpZGVzOiBodHRwczovL3NlYy51bmktc3R1dHRnYXJ0 LmRlL19tZWRpYS9ldmVudHMvb3N3MjAxOS9zbGlkZXMvYmVydG9jY2lfLV9hX2p3dF9wcm9maWxl X2Zvcl9hdHMucHB0eDxodHRwczovL3NlYy4udW5pLXN0dXR0Z2FydC5kZS9fbWVkaWEvZXZlbnRz L29zdzIwMTkvc2xpZGVzL2JlcnRvY2NpXy1fYV9qd3RfcHJvZmlsZV9mb3JfYXRzLnBwdHg+ICkg LSBnb3QgZWFybHkgZmVlZGJhY2sgZnJvbSBGaWxpcCBTa29rYW4gb24gaXQuIFRoeCBGaWxpcCEN CiAgKiAgIFRoZSBwcmVzZW50YXRpb24gd2FzIGZvbGxvd2VkIHVwIGJ5IDEuNSBob3VycyBvZiB1 bmNvbmZlcmVuY2UgZGlzY3Vzc2lvbiwgd2hpY2ggd2FzIGluY3JlZGlibHkgdmFsdWFibGUgdG8g Z2V0IHRpZ2h0LWxvb3AgZmVlZGJhY2sgYW5kIGluY29ycG9yYXRlIG5ldyBpZGVhcy4gSm9obiBC cmFkbGV5LCBCcmlhbiBDYW1wYmVsbCBWbGFkaW1pciBEemh1dmlub3YsIFRvcnN0ZW4gTG9kZGVy c3RlZHQsIE5hdCBTYWtpbXVyYSwgSGFubmVzIFRzY2hvZmVuaWcgd2VyZSBhbGwgdGhlcmUgYW5k IGNvbnRyaWJ1dGVkIGdlbmVyb3VzbHkgdG8gdGhlIGRpc2N1c3Npb24uIFRoYW5rIHlvdSEhIQ0K Tm90ZTogaWYgeW91IHdlcmUgYXQgT1NXMjAxOSwgcGFydGljaXBhdGVkIGluIHRoZSBkaXNjdXNz aW9uIGFuZCBkaWRuJ3QgZ2V0IGNyZWRpdGVkIGluIHRoZSBkcmFmdCwgbXkgYXBvbG9naWVzOiBw bGVhc2Ugc2VuZCBtZSBhIG5vdGUgYW5kIEknbGwgbWFrZSB0aGluZ3MgcmlnaHQgYXQgdGhlIG5l eHQgdXBkYXRlLg0KICAqICAgT24gbXkgZmxpZ2h0IGJhY2sgSSBkaWQgbXkgYmVzdCB0byBpbmNv cnBvcmF0ZSBhbGwgdGhlIGlkZWFzIGFuZCBmZWVkYmFjayBpbiBhIGRyYWZ0LCB3aGljaCB3aWxs IGJlIGRpc2N1c3NlZCBhdCBJRVRGMTA0IHRvbW9ycm93LiBSaWZhYXQsIEhhbm5lcyBhbmQgYWJv dmUgYWxsIEJyaWFuIHdlcmUgYWxsIHN1cGVyIGhlbHBmdWwgaW4gbmVnb3RpYXRpbmcgdGhlIG15 c3RlcmlvdXMgc3ludGF4IG9mIHRoZSBSRkMgZm9ybWF0IGFuZCBzdWJtaXNzaW9uIHByb2Nlc3Mu DQpJIHdhcyBibG93biBhd2F5IGJ5IHRoZSBhdmFpbGFiaWxpdHksIGludm9sdmVtZW50IGFuZCB3 aWxsaW5nbmVzcyB0byBpbnZlc3QgdGltZSB0byBnZXQgdGhpbmdzIHJpZ2h0IHRoYXQgZXZlcnlv bmUgZGVtb25zdHJhdGVkIGluIHRoZSBwcm9jZXNzLiBUaGlzIGlzIGFuIGFtYXppbmcgY29tbXVu aXR5Lg0KVi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQoNCi0tDQpoYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTxtYWlsdG86 aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU+DQpabWFydFpvbmUgSUFNIC0gd3d3LnptYXJ0em9u ZS5ldTxodHRwOi8vd3d3LnptYXJ0em9uZS5ldT4NCg0KDQotLQ0KaGFucy56YW5kYmVsdEB6bWFy dHpvbmUuZXU8bWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1Pg0KWm1hcnRab25lIElB TSAtIHd3dy56bWFydHpvbmUuZXU8aHR0cDovL3d3dy56bWFydHpvbmUuZXU+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KLS0NCg0K --_000_HE1PR0102MB25855DAD2D8674E96AD4118DF75F0HE1PR0102MB2585_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIg MiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkxhdG87fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUmVu IHRla3N0IFRlZ24iOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlJlbnRla3N0VGVnbg0KCXttc28tc3R5bGUt bmFtZToiUmVuIHRla3N0IFRlZ24iOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUmVuIHRla3N0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLmdtYWlsLW0tNzYyNTg3NjU4MDEyMzI5OTQxMGFpcm1haWxvbiwgbGkuZ21haWwtbS03NjI1 ODc2NTgwMTIzMjk5NDEwYWlybWFpbG9uLCBkaXYuZ21haWwtbS03NjI1ODc2NTgwMTIzMjk5NDEw YWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTc2MjU4NzY1ODAxMjMyOTk0MTBh aXJtYWlsX29uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFp bC1tLTc2MjU4NzY1ODAxMjMyOTk0MTBnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0x MjgwNzE3OTY5NTE1MTA2ODE3YWlybWFpbG9uLCBsaS5nbWFpbC1tLTc2MjU4NzY1ODAxMjMyOTk0 MTBnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0xMjgwNzE3OTY5NTE1MTA2ODE3YWly bWFpbG9uLCBkaXYuZ21haWwtbS03NjI1ODc2NTgwMTIzMjk5NDEwZ21haWwtbTgyMDMwNjAxMTM4 NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEwNjgxN2Fpcm1haWxvbg0KCXttc28tc3R5bGUt bmFtZTpnbWFpbC1tXy03NjI1ODc2NTgwMTIzMjk5NDEwZ21haWwtbV84MjAzMDYwMTEzODc3MTY2 OTc2Z21haWwtbV8xMjgwNzE3OTY5NTE1MTA2ODE3YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbS03NjI1ODc2NTgwMTIzMjk5NDEwZ21h aWwtbTgyMDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEwNjgxN2dtYWlsLW04 NDc1NzI4NjU2MjQ1NDkyNDk1YWlybWFpbG9uLCBsaS5nbWFpbC1tLTc2MjU4NzY1ODAxMjMyOTk0 MTBnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0xMjgwNzE3OTY5NTE1MTA2ODE3Z21h aWwtbTg0NzU3Mjg2NTYyNDU0OTI0OTVhaXJtYWlsb24sIGRpdi5nbWFpbC1tLTc2MjU4NzY1ODAx MjMyOTk0MTBnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0xMjgwNzE3OTY5NTE1MTA2 ODE3Z21haWwtbTg0NzU3Mjg2NTYyNDU0OTI0OTVhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6 Z21haWwtbV8tNzYyNTg3NjU4MDEyMzI5OTQxMGdtYWlsLW1fODIwMzA2MDExMzg3NzE2Njk3Nmdt YWlsLW1fMTI4MDcxNzk2OTUxNTEwNjgxN2dtYWlsLW1fODQ3NTcyODY1NjI0NTQ5MjQ5NWFpcm1h aWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVwb3N0 U3RpbDIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FcG9zdFN0aWwy NA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcw Ljg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 MTEwOTE2MzIzMjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwMDE3MjQ0NDg7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox MDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEyODEw NjMzOTg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTQ0Mjg0Mzc2O30NCkBsaXN0IGwxOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNt O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9Ik5P LUJPSyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPldlIGhhdmUgYSBtYWNoaW5lLXRvLW1hY2hpbmUgc2NlbmFyaW8gd2hlcmUgY2xpZW50 cywgUlNlcyBhbmQgb3VyIEFTIGFsbCBiZWxvbmcgdG8gZGlmZmVyZW50IGxlZ2FsIGVudGl0aWVz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Tb21lIFJTZXMgcmVxdWlyZSB0aGVpciBj bGllbnRzIHRvIGxpbWl0IHRoZSBhY2Nlc3MgdG9rZW4gdG8gYSBzcGVjaWZpYyBSZXNvdXJjZSBP d25lciwgd2hpbGUgb3RoZXIgUlNlcyBkb24ndC4gSW4gdGhlIGZvcm1lciBjYXNlLCB3ZSB1c2Ug J3N1YicgdG8gaWRlbnRpZnkgdGhhdCBSZXNvdXJjZSBPd25lci4mbmJzcDsgSW4gc3VjaCBhIG1p eGVkIGRlcGxveW1lbnQgc2NlbmFyaW8sIGFsbG93aW5nIHVzaW5nICdzdWInDQogZm9yIGRpZmZl cmVudCBtZWFuaW5ncyBjYW4gbGVhZCB0byBjb25mdXNpb24sIHNvIEkgdGhpbmsgdGhlIGFjdHVh bCBtZWFuaW5nIHNob3VsZCBiZSBleHBsaWNpdGx5IHNpZ25hbGxlZCBsaWtlIERhdmUgc3VnZ2Vz dHMgYmVsb3cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhhdmluZyBzYWlkIHRoYXQs IEkgZG8gcHJlZmVyIHRvIGxpbWl0IHRoZSB1c2FnZSBvZiAnc3ViJyBpbiBhY2Nlc3MgdG9rZW5z IGZvciB0aGUgRW5kIFVzZXIgb25seS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BcyBhIHNpZGUgbm90 ZSwgaW4gb3VyIGNhc2Ugd2UgbmVlZCBhIG1vcmUgZm9ybWFsIGNsaWVudCBpZGVudGlmaWNhdGlv biB0aGFuIHRoZSBjbGllbnRfaWQgYWxvbmUgKGFzIHRoZXkgYXJlIHJhbmRvbWx5IGdlbmVyYXRl ZCBieSBEQ1IpLCZuYnNwOyBhbmQgaGF2ZSB0aHVzIG9wdGVkIGZvciBhIGN1c3RvbSBjbGFpbSBg Y2xpZW50X293bmVyYCBjb250YWluaW5nIHRoZSByZWdpc3RlcmVkIGNvbXBhbnkgaWRlbnRpZmll ci4mbmJzcDsNCiBXZSBwdWxsIHRoaXMgb3V0IGZyb20gY2VydGlmaWNhdGUgdXNlZCB0byBzaWdu IHRoZSBKV1QtZ3JhbnQgKFJGQzc1MjMpIGZyb20gdGhlIHRva2VuIHJlcXVlc3QuICZuYnNwOyZu YnNwO1dlIGNvdWxkIG9mIGNvdXJzZSBoYXZlIHVzZWQg4oCYc3Vi4oCZIGZvciBjbGllbnRfb3du ZXIsIGJ1dCB0aGF0IHdvdWxkIHJlcXVpcmUgdXMgdG8gaW52ZW50IGFub3RoZXIgY3VzdG9tIGNs YWltIGZvciB0aG9zZSBSU2VzIHRoYXQgcmVxdWlyZXMgUk8tbGltaXRlZCB0b2tlbnMuICZuYnNw OyZuYnNwOyZuYnNwO1RvDQogbWFrZSBtYXR0ZXJzIGV2ZW4gbW9yZSBjb21wbGljYXRlZCwgdGhl cmUgbWlnaHQgYmUgYnVzaW5lc3MgZGVsZWdhdGlvbiBoYXBwZW5pbmcsJm5ic3A7IHdoZXJlIGNv bXBhbnkgQSBydW5uaW5nIHRoZSBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBkaWZmZXJl bnQgb3RoZXIgY29tcGFuaWVzIEIsQyxE4oCmIGFuZCB0aGUgaW5zdGFudGFuZW91cyBBJiM0MztC IG9yIEEmIzQzO0MgcmVsYXRpb24gYWxzbyBoYXZlIHRvIGJlIGNvbW11bmljYXRlZCBpbiB0aGUg dG9rZW4NCiAmbmJzcDsoQWNjb3JkaW5nIHRvIEVVIHByaXZhY3kgbGF3cywgSSBiZWxpdmUgQSBp cyB0aGUgRGF0YSBQcm9jZXNzb3IgYW5kIHRoZWlyIGN1c3RvbWVyIEIsQyxE4oCmIGFyZSBEYXRh IENvbnRyb2xsZXIpLiZuYnNwOyZuYnNwOyBTbyBhZ2FpbiB0aGlzIGxlYWRzIG1lIHRvIHRoaW5r IHRoYXQgY2xpZW50IGlkZW50aWZpY2F0aW9uIHNob3VsZCBiZSBrZXB0IGluIHNlcGFyYXRlIGNs YWltcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QW55d2F5LCBmb3IgdXMgYXMgdXNl ciBvZiB0aGUgb2F1dGgyIHByb3RvY29scywgdGhpcyBkcmFmdCBpcyB3ZWxjb21lICE8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5LaW5kIHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5Kw7hyZ2VuIEJpbm5pbmdzYsO4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Qcm9kdWN0IE93bmVyLCBOb3J3ZWdpYW4gTmF0aW9u YWwgZUlEIEluZnJhc3RydWN0dXJlIChJRC1wb3J0ZW4pPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyYTo8L2I+IE9BdXRoICZsdDtvYXV0aC1ib3Vu Y2VzQGlldGYub3JnJmd0OyA8Yj5Qw6UgdmVnbmUgYXY8L2I+IERhdmUgVG9uZ2U8YnI+DQo8Yj5T ZW5kdDo8L2I+IHRpcnNkYWcgMjYuIG1hcnMgMjAxOSAwOS4yNzxicj4NCjxiPlRpbDo8L2I+IERv bWluaWNrIEJhaWVyICZsdDtkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tJmd0Ozxicj4NCjxiPktv cGk6PC9iPiBJRVRGIG9hdXRoIFdHICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5FbW5l OjwvYj4gUmU6IFtPQVVUSC1XR10gZHJhZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3 dC0wMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPlRo YW5rcyBWaXR0b3JpbyBmb3IgeW91ciBwcmVzZW50YXRpb24gYW5kIHB1dHRpbmcgdGhpcyBkcmFm dCB0b2dldGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1T JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+SSBhZ3JlZSB3aXRoIERvbWluY2sgdGhh dCB0aGVyZSBpcyBhIHBvdGVudGlhbCBvZiB0aGluZ3MgZ29pbmcgd3Jvbmcgd2hlbiBgc3ViYCBo YXMgbXVsdGlwbGUgbWVhbmluZ3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Ry ZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5Ib3dldmVyIEkgY2FuIHNlZSB0aGF0IHVzaW5n IGBzdWJgIGZvciBhIGNsaWVudF9pZCBzZW1hbnRpY2FsbHkgbWFrZXMgc2Vuc2UgaW4gc29tZSBz aXR1YXRpb25zIGFuZCBJIGFncmVlIHRoYXQgaXQgbWFrZXMgaXQgc2ltcGxlciBmcm9tIGFuIFNE SyBwb2ludCBvZiB2aWV3IGZvciB0aGVyZSB0byBhbHdheXMgYmUgYSBgc3ViYC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDss c2Fucy1zZXJpZiI+TXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0aGF0IGVpdGhlciB0aGVyZSBpcyBh biBleHBsaWNpdCB0eXBlIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiAmcXVvdDt1c2VyIGFjY2Vz cyB0b2tlbnMmcXVvdDsgYW5kICZxdW90O2FwcGxpY2F0aW9uIGFjY2VzcyB0b2tlbnMmcXVvdDss IG9yIGZhaWxpbmcgdGhhdCB0aGUgYHN1YmAgaXMgdXNlZCB0byBpbmRpY2F0ZQ0KIHRoZSBkaWZm ZXJlbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Ry ZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5GdXJ0aGVybW9yZSBhbiBhZ3JlZW1lbnQgb24g dGhlIG5hbWluZyBhbmQgZGVzY3JpcHRpb24gb2YgdGhlc2UgdHdvIHR5cGVzIG9mIGFjY2VzcyB0 b2tlbnMgd291bGQgYmUgaGVscGZ1bCBtb3JlIGdlbmVyYWxseS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJp ZiI+RGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVHVlLCAyNiBNYXIgMjAxOSBhdCAwNzoyNSwgRG9taW5pY2sgQmFpZXIg Jmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIj5kYmFpZXJAbGVh c3Rwcml2aWxlZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbSBhbiBhY2Nl c3MgdG9rZW4gY29uc3VtZXIgKGFrYSBBUEkpIGRldmVsb3BlciBwb2ludCBvZiB2aWV3LCBJIHBy ZWZlciB0aGlzIGxvZ2ljPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mcXVvdDtJZiBzdWIgaXMgcHJlc2VudCAtIGNsaWVudCBhY3RzIG9uIGJlaGFsZiBv ZiBhIHVzZXIsIGlmIG5vdCAtIG5vdC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFueXRoaW5nIG1vcmUgY29tcGxpY2F0ZWQgaGFzIGEgcG90 ZW50aWFsIG9mIGdvaW5nIHdyb25nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTc2MjU4NzY1ODAx MjMyOTk0MTBhaXJtYWlsb24iPk9uIDI2LiBNYXJjaCAyMDE5IGF0IDAxOjM0OjUzLCBOb3YgTWF0 YWtlICg8YSBocmVmPSJtYWlsdG86bWF0YWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1h dGFrZUBnbWFpbC5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFZpdHRvcmlvLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZWFoLCBJ4oCZ bSBjb25jZXJuaW5nIHVzZXIgJmFtcDsgY2xpZW50IGlkcyBjb2xsaXNpb24uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmVu4oCZdCBzZWVu IHN1Y2ggaW1wbGVtZW50YXRpb25zLCBidXQgdXNlci1zZWxlY3QgdXNlcm5hbWUgYXMgc3ViLCBv ciBpbmNyZW1lbnRhbCBpbnRlZ2VyIGFzIHN1YiAmYW1wOyBjbGllbnRfaWQgd2lsbCBiZSBlYXNp bHkgY29sbGlkZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SWYgeW91IGNhbiBlbmZvcmNlIGNvbGxpc2lvbiByZXNpc3RhbnQgSURzIGJldHdl ZW4gdXNlciAmYW1wOyBjbGllbnQgaW5zdGFuY2VzLCBpdOKAmWxsIHdvcmtzIGZpbmUuIEkgZmVl bCBpdHMgb3ZlcmtpbGwgdGhvdWdoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0i Z21haWwtbV8tNzYyNTg3NjU4MDEyMzI5OTQxMEFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TZW50IGZyb20gbXkgaVBob25lPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCk9uIE1hciAyNiwgMjAxOSwgYXQgODo1MSwgVml0dG9yaW8gQmVydG9jY2kgJmx0Ozxh IGhyZWY9Im1haWx0bzpWaXR0b3Jpb0BhdXRoMC5jb20iIHRhcmdldD0iX2JsYW5rIj5WaXR0b3Jp b0BhdXRoMC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhleSBOb3YsIERvbWluaWNrLCBIYW5zLSA8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFua3MgZm9yIHRo ZSBjb21tZW50cy4gVGhhdCB3YXMgYW4gYXJlYSBJIHdhcyBleHBlY3RpbmcgdG8gY2F1c2UgbW9y ZSBkaXNjdXNzaW9uLCBhbmQgSSBhbSBnbGFkIHdlIGFyZSBoYXZpbmcgdGhpcyBvcHBvcnR1bml0 eSB0byBjbGFyaWZ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIGN1cnJlbnQgbGFuZ3VhZ2UgaW4gdGhlIGRyYWZ0IHRyYWNlcyB0aGUgZXR5 bW9sb2d5IG9mIHN1YiB0byBPcGVuSUQgQ29ubmVjdCBjb3JlLCBoZW5jZSBEb21pbmljayBvYnNl cnZhdGlvbiBpcyBvbiBwb2ludC4gSG93ZXZlciBpbiB0aGUgZGVzY3JpcHRpb24gSSBleHByZXNz IHNvbWV0aGluZyBpbiBsaW5lIHdpdGggNzUxOSwgd2hpY2ggd2FzIGluIGZhY3QgbXkgaW50ZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgaWRlYSB3YXMgdG8gcHJvdmlkZSBhbiBpZGVudGlmaWVyIG9mIHRoZSBjYWxsaW5nIHN1Ympl Y3QgdGhhdCBpcyBndWFyYW50ZWVkIHRvIGJlIHByZXNlbnQgaW4gYWxsIGNhc2VzLSB0aGlzIHdv dWxkIGFsbG93IGFuIFNESyBkZXZlbG9wZXIgdG8gdXNlIHRoZSBzYW1lIGNvZGUgZm9yIHRoaW5n cyBsaWtlIGxvb2t1cHMgYW5kIG1lbWJlcnNoaXAgY2hlY2tzIHJlZ2FyZGxlc3Mgb2YgdGhlIG5h dHVyZSBvZg0KIHRoZSBjYWxsZXIgKHVzZXIgaW4gYSBkZWxlZ2F0ZWQgY2FzZSwgYXBwIGluIGFw cC1vbmx5IGdyYW50cykuIFRoZSBpbmZvcm1hdGlvbiB0byBkaXNjcmltaW5hdGUgYmV0d2VlbiB1 c2VyIGFuZCBhcHAgY2FsbGVycyBpcyBhbHdheXMgYXZhaWxhYmxlIGluIHRoZSB0b2tlbiAoc2F5 LCB0aGUgY2FsbGVyIGlzIGEgdXNlciBpZiBzdWIhPWNsaWVudF9pZCwgd2hlcmUgY2xpZW50X2lk IGlzIGFsd2F5cyBndWFyYW50ZWVkIHRvIGJlIHByZXNlbnQgYXMNCiB3ZWxsKSBoZW5jZSB0aGVy ZSdzIG5vIGxvc3MgaW4gZXhwcmVzc2l2ZSBwb3dlciwgc2hvdWxkIHRoYXQgZGlmZmVyZW5jZSBi ZSByZWxldmFudCBmb3IgdGhlIHJlc291cmNlIHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9taW5pY2ssIEhhbnMtIEkgcHJvYmFi bHkgbWlzc2VkIHRoZSBzZWN1cml0eSBpc3N1ZSB5b3UgZ3V5cyBhcmUgdGhpbmtpbmcgb2YgaW4g dGhpcyBjYXNlLiBPZiBjb3Vyc2UsIGlmIHRoaXMgd291bGQgaW50cm9kdWNlIGEgcmlzayBJIGNv bXBsZXRlbHkgYWdyZWUgaXQgc2hvdWxkIGJlIGNoYW5nZWQtIEknZCBqdXN0IGxpa2UgdG8gdW5k ZXJzdGFuZCBiZXR0ZXIgdGhlIHByb2JsZW0uIENvdWxkIHlvdSBleHBhbmQNCiBpdCBpbiBhIHNj ZW5hcmlvL3VzZSBjYXNlIHRvIGNsYXJpZnkgdGhlIHJpc2s/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3YtIHBsYXlpbmcgdGhpcyBiYWNrOiBp cyB0aGUgY29uY2VybiB0aGF0IGEgdXNlciBhbmQgYSBjbGllbnQgbWlnaHQgaGF2ZSB0aGUgc2Ft ZSBpZGVudGlmaWVyIHdpdGhpbiBhbiBJRFA/IFdoZW4gdXNpbmcgY29sbGlzaW9uIHJlc2lzdGFu dCBJRHMsIGFzIGl0IGlzIHVzdWFsbHkgdGhlIGNhc2UsIHRoYXQgc2VlbXMgdG8gYmUgYSByZW1v dGUgcG9zc2liaWxpdHktIGRpZCB5b3Ugc3R1bWJsZSBpbiBzdWNoDQogc2NlbmFyaW8gaW4gcHJv ZHVjdGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5WLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDc6NDQgQU0gSGFucyBaYW5k YmVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1IiB0YXJn ZXQ9Il9ibGFuayI+aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXU8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2 ZSB0aGVyZSBhcmUgcGxlbnR5IG9mIE9BdXRoIDIuMCBvbmx5IHVzZSBjYXNlcyBvdXQgdGhlcmUu Li4gYnV0IG5ldmVydGhlbGVzcyBJIGFncmVlIHdpdGggdGhlIHBvdGVudGlhbCBjb25mdXNpb24g YW5kIHRodXMgc2VjdXJpdHkgcHJvYmxlbXMgYXJpc2luZyBmcm9tIHRoYXQgKHRob3VnaCBvbmUg bWF5IGFyZ3VlIHRoZSBzZW1hbnRpY3MgYXJlIHRoZSBzYW1lKS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDM6 MzkgUE0gRG9taW5pY2sgQmFpZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmFpZXJAbGVhc3Rwcml2 aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlllcyBJIGtub3cgLSBhbmQgSSB0aGluayBpbiBoaW5k c2lnaHQgaXQgd2FzIGEgbWlzdGFrZSB0byB1c2UgdGhlIHNhbWUgY2xhaW0gdHlwZSBmb3IgbXVs dGlwbGUgc2VtYW50aWNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+QWxsIHRoZSDigJx0aGlzIGlzIE9JREMgbm90IE9BdXRo4oCdIGFyZ3VtZW50cyBh cmUgbWFraW5nIHRoaW5ncyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhleSBuZWVkIHRvIGJlIC0g aW4gbXkgZXhwZXJpZW5jZSBhbG1vc3Qgbm8tb25lICh0aGF0IEkga25vdykgZG9lcyBPSURDIG9u bHkgLSBub3IgT0F1dGgNCiBvbmx5LiBUaGV5IGFsd2F5cyBjb21iaW5lIGl0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gcmVhbGl0eSB0aGlzIGxl YWRzIHRvIHBvdGVudGlhbCBzZWN1cml0eSBwcm9ibGVtcyAtIHRoaXMgc3BlYyBoYXMgdGhlIHBv dGVudGlhbCB0byByZWN0aWZ5IHRoZSBzaXR1YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbWluaWNrPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tLTc2MjU4NzY1ODAxMjMyOTk0MTBnbWFpbC1tODIwMzA2MDExMzg3NzE2Njk3NmdtYWlsLW0x MjgwNzE3OTY5NTE1MTA2ODE3YWlybWFpbG9uIj4NCk9uIDI1LiBNYXJjaCAyMDE5IGF0IDE0OjU4 OjU2LCBIYW5zIFphbmRiZWx0ICg8YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpv bmUuZXUiIHRhcmdldD0iX2JsYW5rIj5oYW5zLnphbmRiZWx0QHptYXJ0em9uZS5ldTwvYT4pIHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRob3V0IGFncmVlaW5nIG9yIGRpc2FncmVl aW5nOiBPSURDIGRvZXMgbm90IGFwcGx5IGhlcmUgc2luY2UgaXQgaXMgbm90IE9BdXRoIGFuZCBh biBhY2Nlc3MgdG9rZW4gaXMgbm90IGFuIGlkX3Rva2VuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIEpXVCBzcGVjIHNheXMgaW4gPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlvbi00LjEuMiIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTkjc2VjdGlv bi00LjEuMjwvYT46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mcXVvdDtUaGUgJnF1b3Q7c3ViJnF1b3Q7IChzdWJqZWN0KSBjbGFpbSBpZGVudGlmaWVzIHRo ZSBwcmluY2lwYWwgdGhhdCBpcyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtzdWJqZWN0IG9mIHRoZSBKV1QuJm5ic3A7 IFRoZSBjbGFpbXMgaW4gYSBKV1QgYXJlIG5vcm1hbGx5IHN0YXRlbWVudHM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDthYm91 dCB0aGUgc3ViamVjdC4mbmJzcDsgVGhlIHN1YmplY3QgdmFsdWUgTVVTVCBlaXRoZXIgYmUgc2Nv cGVkIHRvIGJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7bG9jYWxseSB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlz c3VlciBvciBiZSBnbG9iYWxseSB1bmlxdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7VGhlIHByb2Nlc3Npbmcgb2YgdGhp cyBjbGFpbSBpcyBnZW5lcmFsbHkgYXBwbGljYXRpb24gc3BlY2lmaWMmcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hpY2gga2luZCBv ZiBzcGVsbHMgJnF1b3Q7Y2xpZW50JnF1b3Q7IGluIGNhc2Ugb2YgdGhlIGNsaWVudCBjcmVkZW50 aWFscyBncmFudCBidXQgSSBhbHNvIGRvIHdvcnJ5IGFib3V0IFJlc291cmNlIFNlcnZlcnMgdGhp bmtpbmcvYWN0aW5nIG9ubHkgaW4gdGVybXMgb2YgdXNlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFucy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1v biwgTWFyIDI1LCAyMDE5IGF0IDI6NDEgUE0gRG9taW5pY2sgQmFpZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJhaWVyQGxl YXN0cHJpdmlsZWdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklNSE8gdGhlIHN1 YiBjbGFpbSBzaG91bGQgYWx3YXlzIHJlZmVyIHRvIHRoZSB1c2VyIC0gYW5kIG5vdGhpbmcgZWxz ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9JREMg c2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZx dW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlN1YmplY3QgLSBJZGVudGlmaWVyIGZvciB0aGUg RW5kLVVzZXIgYXQgdGhlIElzc3Vlci4mcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Y2xpZW50X2lkIHNob3VsZCBiZSB1c2VkIHRvIGlkZW50aWZ5IGNsaWVudHMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNoZWVyczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9taW5pY2s8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS03NjI1ODc2NTgwMTIzMjk5NDEwZ21haWwtbTgy MDMwNjAxMTM4NzcxNjY5NzZnbWFpbC1tMTI4MDcxNzk2OTUxNTEwNjgxN2dtYWlsLW04NDc1NzI4 NjU2MjQ1NDkyNDk1YWlybWFpbG9uIj4NCk9uIDI1Li4gTWFyY2ggMjAxOSBhdCAwNToxMzowMywg Tm92IE1hdGFrZSAoPGEgaHJlZj0ibWFpbHRvOm1hdGFrZUBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5tYXRha2VAZ21haWwuY29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgVml0dG9yaW8sIDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgZ29vZCBzdGFy dGluZyBwb2ludCBvZiBzdGFuZGFyZGl6aW5nIEpXVC1pemVkIEFULjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgZmVlZGJhY2suPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg4oCcc3Vi 4oCdIGNsYWltIGNhbiBpbmNsdWRlIDIgdHlwZXMgb2YgaWRlbnRpZmllciwgZW5kLXVzZXIgYW5k IGNsaWVudCwgaW4gdGhpcyBzcGVjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SXQgcmVxdWlyZXMgdGhvc2UgMiB0eXBlcyBvZiBpZGVudGlmaWVy cyB0byBiZSB1bmlxdWUgZWFjaCBvdGhlciBpbiB0aGUgSWRQIGNvbnRleHQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcHJlZmVyIG9taXR0 aW5nIOKAnHN1YuKAnSBjbGFpbSBpbiAyLWxlZ2dlZCBjb250ZXh0LCBzbyB0aGF0IG5vIHN1Y2gg Y29uc3RyYWludCBuZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5ub3Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAyNSwgMjAxOSwgYXQgODoyOSwgVml0 dG9yaW8gQmVydG9jY2kgJmx0OzxhIGhyZWY9Im1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaT00MGF1 dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnZpdHRvcmlvLmJlcnRvY2Np PTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgYWxsLCA8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGp1c3Qgc3VibWl0 dGVkIGEgZHJhZnQgZGVzY3JpYmluZyBhIEpXVCBwcm9maWxlIGZvciBPQXV0aCAyLjAgYWNjZXNz IHRva2Vucy4gWW91IGNhbiBmaW5kIGl0IGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVydG9jY2ktb2F1dGgtYWNjZXNzLXRva2VuLWp3dC8i IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1i ZXJ0b2NjaS1vYXV0aC1hY2Nlc3MtdG9rZW4tand0LzwvYT4uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYSBzbG90IHRvIGRpc2N1c3Mg dGhpcyB0b21vcnJvdyBhdCBJRVRGIDEwNCAoSSdsbCBiZSBwcmVzZW50aW5nIHJlbW90ZWx5KS4g SSBsb29rIGZvcndhcmQgZm9yIHlvdXIgY29tbWVudHMhPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUncyBqdXN0IGEgYml0IG9mIGJhY2tz dG9yeSwgaW4gY2FzZSB5b3UgYXJlIGludGVyZXN0ZWQgaW4gaG93IHRoaXMgZG9jIGNhbWUgdG8g YmUuIFRoZSB0cmFqZWN0b3J5IGl0IGZvbGxvd2VkIGlzIHNvbWV3aGF0IHVudXN1YWwuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCkRlc3BpdGUgT0F1dGgyIG5vdCBy ZXF1aXJpbmcgYW55IHNwZWNpZmljIGZvcm1hdCBmb3IgQVRzLCB0aHJvdWdoIHRoZSB5ZWFycyBJ IGhhdmUgY29tZSBhY3Jvc3MgbXVsdGlwbGUgcHJvcHJpZXRhcnkgc29sdXRpb24gdXNpbmcgSldU IGZvciB0aGVpciBhY2Nlc3MgdG9rZW4uIFRoZSBpbnRlbnQgYW5kIHNjZW5hcmlvcyBhZGRyZXNz ZWQgYnkgdGhvc2Ugc29sdXRpb25zIGFyZSBtb3N0bHkgdGhlIHNhbWUgYWNyb3NzIHZlbmRvcnMs IGJ1dCB0aGUNCiBzeW50YXggYW5kIGludGVycHJldGF0aW9ucyBpbiB0aGUgaW1wbGVtZW50YXRp b25zIGFyZSBkaWZmZXJlbnQgZW5vdWdoIHRvIHByZXZlbnQgZGV2ZWxvcGVycyBmcm9tIHJldXNp bmcgY29kZSBhbmQgc2tpbGxzIHdoZW4gbW92aW5nIGZyb20gcHJvZHVjdCB0byBwcm9kdWN0Ljxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBs Zm8zIj4NCkkgYXNrZWQgc2V2ZXJhbCBpbmRpdmlkdWFscyBmcm9tIGtleSBwcm9kdWN0cyBhbmQg c2VydmljZXMgdG8gc2hhcmUgd2l0aCBtZSBjb25jcmV0ZSBleGFtcGxlcyBvZiB0aGVpciBKV1Qg YWNjZXNzIHRva2VucyAoVEhBTksgWU9VIERvbWluaWNrIEJhaWVyIChJZGVudGl0eVNlcnZlciks Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkJyaWFuIENhbXBiZWxsIChQaW5n SWRlbnRpdHkpLCBEYW5pZWwgRG9iYWxpYW4gKE1pY3Jvc29mdCksIEthcmwNCiBHdWlubmVzcyAo T2t0YSkgZm9yIHRoZSB0b2tlbnMgYW5kIGV4cGxhbmF0aW9ucyE8L3NwYW4+KS48YnI+DQpJIHN0 dWRpZWQgYW5kIGNvbXBhcmVkIGFsbCB0aG9zZSBpbnN0YW5jZXMsIGlkZW50aWZ5aW5nIGNvbW1v bmFsaXRpZXMgYW5kIGRpZmZlcmVuY2VzLiZuYnNwOzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCkkgcHV0IHRvZ2V0aGVyIGEg cHJlc2VudGF0aW9uIHN1bW1hcml6aW5nIG15IGZpbmRpbmdzIGFuZCBzdWdnZXN0aW5nIGEgcm91 Z2ggaW50ZXJvcGVyYWJsZSBwcm9maWxlIChzbGlkZXM6DQo8YSBocmVmPSJodHRwczovL3NlYy4u dW5pLXN0dXR0Z2FydC5kZS9fbWVkaWEvZXZlbnRzL29zdzIwMTkvc2xpZGVzL2JlcnRvY2NpXy1f YV9qd3RfcHJvZmlsZV9mb3JfYXRzLnBwdHgiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vc2Vj LnVuaS1zdHV0dGdhcnQuZGUvX21lZGlhL2V2ZW50cy9vc3cyMDE5L3NsaWRlcy9iZXJ0b2NjaV8t X2Ffand0X3Byb2ZpbGVfZm9yX2F0cy5wcHR4PC9hPiApIC0gZ290IGVhcmx5IGZlZWRiYWNrIGZy b20gRmlsaXAgU2tva2FuIG9uIGl0LiBUaHggRmlsaXAhPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KVGhlIHByZXNlbnRhdGlv biB3YXMgZm9sbG93ZWQgdXAgYnkgMS41IGhvdXJzIG9mIHVuY29uZmVyZW5jZSBkaXNjdXNzaW9u LCB3aGljaCB3YXMgaW5jcmVkaWJseSB2YWx1YWJsZSB0byBnZXQgdGlnaHQtbG9vcCBmZWVkYmFj ayBhbmQgaW5jb3Jwb3JhdGUgbmV3IGlkZWFzLiBKb2huIEJyYWRsZXksIEJyaWFuIENhbXBiZWxs IFZsYWRpbWlyIER6aHV2aW5vdiwgVG9yc3RlbiBMb2RkZXJzdGVkdCw8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jm5ic3A7TmF0DQogU2FraW11cmEsIEhhbm5lcyBUc2Nob2ZlbmlnPC9z cGFuPiZuYnNwO3dlcmUgYWxsIHRoZXJlIGFuZCBjb250cmlidXRlZCBnZW5lcm91c2x5IHRvIHRo ZSBkaXNjdXNzaW9uLiBUaGFuayB5b3UhISE8YnI+DQpOb3RlOiBpZiB5b3Ugd2VyZSBhdCBPU1cy MDE5LCBwYXJ0aWNpcGF0ZWQgaW4gdGhlIGRpc2N1c3Npb24gYW5kIGRpZG4ndCBnZXQgY3JlZGl0 ZWQgaW4gdGhlIGRyYWZ0LCBteSBhcG9sb2dpZXM6IHBsZWFzZSBzZW5kIG1lIGEgbm90ZSBhbmQg SSdsbCBtYWtlIHRoaW5ncyByaWdodCBhdCB0aGUgbmV4dCB1cGRhdGUuPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KT24gbXkg ZmxpZ2h0IGJhY2sgSSBkaWQgbXkgYmVzdCB0byBpbmNvcnBvcmF0ZSBhbGwgdGhlIGlkZWFzIGFu ZCBmZWVkYmFjayBpbiBhIGRyYWZ0LCB3aGljaCB3aWxsIGJlIGRpc2N1c3NlZCBhdCBJRVRGMTA0 IHRvbW9ycm93LiBSaWZhYXQsIEhhbm5lcyBhbmQgYWJvdmUgYWxsIEJyaWFuIHdlcmUgYWxsIHN1 cGVyIGhlbHBmdWwgaW4gbmVnb3RpYXRpbmcgdGhlIG15c3RlcmlvdXMgc3ludGF4IG9mIHRoZSBS RkMgZm9ybWF0IGFuZCBzdWJtaXNzaW9uDQogcHJvY2Vzcy48bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyBibG93biBhd2F5IGJ5IHRoZSBhdmFp bGFiaWxpdHksIGludm9sdmVtZW50IGFuZCB3aWxsaW5nbmVzcyB0byBpbnZlc3QgdGltZSB0byBn ZXQgdGhpbmdzIHJpZ2h0IHRoYXQgZXZlcnlvbmUgZGVtb25zdHJhdGVkIGluIHRoZSBwcm9jZXNz LiBUaGlzIGlzIGFuIGFtYXppbmcgY29tbXVuaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5WLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRo IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9B dXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBocmVmPSJtYWlsdG86aGFucy56YW5kYmVsdEB6bWFydHpvbmUuZXUiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+aGFucy56YW5kYmVsdEB6bWFydHpvbmUu ZXU8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Wm1hcnRab25lIElBTSAtIDwvc3Bhbj48YSBocmVmPSJodHRw Oi8vd3d3LnptYXJ0em9uZS5ldSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij53d3cuem1hcnR6b25lLmV1PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOmhhbnMuemFuZGJl bHRAem1hcnR6b25lLmV1IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPmhhbnMuemFuZGJlbHRAem1hcnR6b25lLmV1PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlptYXJ0 Wm9uZSBJQU0gLSA8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy56bWFydHpvbmUuZXUiIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+d3d3LnptYXJ0em9uZS5l dTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6TGF0bztjb2xvcjojMDBBNEI3Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_HE1PR0102MB25855DAD2D8674E96AD4118DF75F0HE1PR0102MB2585_-- From nobody Wed Mar 27 02:09:00 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D0C12027D; Wed, 27 Mar 2019 02:08:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ekr@rtfm.com, Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, draft-ietf-oauth-device-flow@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155367771404.10327.7807731613641862967.idtracker@ietfa.amsl.com> Date: Wed, 27 Mar 2019 02:08:34 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'OAuth 2.0 Device Authorization Grant' to Proposed Standard (draft-ietf-oauth-device-flow-15.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 09:08:38 -0000 The IESG has approved the following document: - 'OAuth 2.0 Device Authorization Grant' (draft-ietf-oauth-device-flow-15.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Benjamin Kaduk and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ Technical Summary This OAuth 2.0 authorization flow for browserless and input constrained devices, often referred to as the device flow, enables OAuth clients to request user authorization from devices that have an Internet connection, but don't have an easy input method (such as a smart TV, media console, picture frame, or printer), or lack a suitable browser for a more traditional OAuth flow. This authorization flow instructs the user to perform the authorization request on a secondary device, such as a smartphone. There is no requirement for communication between the constrained device and the user's secondary device. Working Group Summary The device flow used to be part of the OAuth 2.0 specification, but it was later moved to its own separate document based on the WG feedback and support: https://mailarchive.ietf.org/arch/msg/oauth/pQafddqfV3W3U_skHuR7E6ZQ44I https://mailarchive.ietf.org/arch/msg/oauth/U7FsPASLxhNz4eB2FNypw4n952c The WG document received many reviews and feedbacks from multiple WG members on the mailing list and during the WG meetings. Document Quality The document has been implemented by Google, Facebook, Microsoft, ForgeRock, Salesforce, Curity Identity Server, and MITREid Connect. https://developers.google.com/youtube/v3/guides/auth/devices https://developers.facebook.com/docs/facebook-login/for-devices https://github.com/Azure-Samples/active-directory-dotnet-deviceprofile https://backstage.forgerock.com/docs/am/5.5/oauth2-guide/#rest-api-oauth2-device-flow https://releasenotes.docs.salesforce.com/en-us/spring17/release-notes/rn_security_auth_device_flow.htm https://www.curity.io/product/ https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server Also, it seems that ETSI has a specification based on this document: https://www.ietf.org/mail-archive/web/oauth/current/msg15969.html https://mailarchive.ietf.org/arch/msg/oauth/23ARrozt4RUUHA_NRiet7c38oIA http://www.etsi.org/deliver/etsi_ts/103400_103499/103407/01.01.01_60/ts_103407v010101p.pdf https://tech.ebu.ch/groups/CPA There is also a different use for this mechanism as stated here: https://mailarchive.ietf.org/arch/msg/oauth/VzEo9rqC3kmqCuLFR-JcYQvIM3Q Personnel The document shepherd is Rifaat Shekh-Yusef. The responsible Area Director is Eric Rescorla. From nobody Wed Mar 27 04:11:26 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321751202A9 for ; Wed, 27 Mar 2019 04:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 clEI-5aBUVya for ; Wed, 27 Mar 2019 04:11:22 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0621.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::621]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF4E120254 for ; Wed, 27 Mar 2019 04:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nu0eUvZlGCY23ehZ9/C1WmrnO7Z82qXw3ztPyxBqomY=; b=GxRaCPhf2OMsr4E3tJ7L/ZvRb+GcDE/PlZy8LvHsqAqSbQ144O49/E3p32Q/XThpJyu/Szdw480ZfCh34xgTLYgsOmRsk36hrhIgS5CigM2kAt6rVrqYezJtjje52jeQk+BObtISZvGu+8+MuM+6pwC2rvQ31EH/h3QzAFIs59g= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1551.eurprd08.prod.outlook.com (10.167.210.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Wed, 27 Mar 2019 11:11:19 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65%11]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 11:11:19 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: [Teep] Fwd: Side-meeting: Canonical JSON, Signed REST Thread-Index: AQHU5HajiaXN3l/2nEOIUhbOg7K88KYfUlGg Date: Wed, 27 Mar 2019 11:11:19 +0000 Message-ID: References: <4944d01f-4565-9688-8833-1c8b287c6ae0@gmail.com> <5e1c4ee8-0e8f-d1b7-2fca-759d2aaadb45@gmail.com> In-Reply-To: <5e1c4ee8-0e8f-d1b7-2fca-759d2aaadb45@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [2001:67c:1232:144:f989:c517:2fd4:9426] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 010b74e3-a605-48fd-0cd6-08d6b2a4f02b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1551; x-ms-traffictypediagnostic: VI1PR0801MB1551: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 0989A7979C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(366004)(346002)(376002)(40434004)(189003)(199004)(6506007)(486006)(105586002)(229853002)(53936002)(561944003)(186003)(6306002)(476003)(6436002)(7696005)(446003)(9686003)(2473003)(106356001)(102836004)(55016002)(11346002)(46003)(99286004)(33656002)(81166006)(76176011)(81156014)(6116002)(8676002)(305945005)(14454004)(74316002)(2906002)(114624004)(7736002)(5660300002)(52536014)(25786009)(6916009)(316002)(97736004)(68736007)(256004)(5024004)(14444005)(71190400001)(71200400001)(72206003)(478600001)(966005)(86362001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1551; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Qp3pdsXecp4vBeMb0fDEaDwl3CQqMI2U1UAAUeM33tobD9BriEv2HTd2WDTJBheNkVB7AvaFKVL9/nzk8YxIQnpBb01VcVDLn9e9AQOSstF+SjT0HjEhDX6Rm+npR64PiaH1EJ7MQG2QmIzTdfl+gP3oafmDBreClJRQOg/Y4HoiUZDXR91egMh+LxApHR4TnhIc4xq1oW9JBF4hn52iggcSzvFtT1+dZyVRcXkRCpXwR3qU6BEn+aJxvO82SRNSAx5qKQTi92wGv4oTOVR5MqxXhTH1lpFY7H/XQi8CMiARiYdPRv+ayu/SpCdJIDuWvsPJc480aknn+R+FG7g5tJPNg0y+5jErEAy5EygtT0QNKv85s7xhcujSlg1/xr90vlfJ0IvUEqUi5B5scyJBh+zMe3Hix2JriPhA63CGla4= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 010b74e3-a605-48fd-0cd6-08d6b2a4f02b X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 11:11:19.1756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1551 Archived-At: Subject: [OAUTH-WG] FW: [Teep] Fwd: Side-meeting: Canonical JSON, Signed REST X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 11:11:25 -0000 VGhpcyBtYXkgYWxzbyBiZSBvZiBpbnRlcmVzdCB0byB0aGUgZm9sa3MgaW4gT0F1dGgNCg0KLS0t LS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6IFNpZGUtbWVldGluZzog Q2Fub25pY2FsIEpTT04sIFNpZ25lZCBSRVNUDQpEYXRlOiBXZWQsIDI3IE1hciAyMDE5IDA2OjUy OjM5ICswMTAwDQpGcm9tOiBBbmRlcnMgUnVuZGdyZW4gPGFuZGVycy5ydW5kZ3Jlbi5uZXRAZ21h aWwuY29tPg0KVG86IDEwNEF0dGVuZGVlcyA8MTA0YXR0ZW5kZWVzQGlldGYub3JnPg0KDQpXZWRu ZXNkYXkgMTQtMTUgaW4gUGFyaXMuDQoNCk15IHByZXNlbnRhdGlvbnMgYXQgSUVURi0xMDQgY291 bGRuJ3QgZ28gaW50byBkZXRhaWxzLCBzbyBoZXJlIHNvbWUgYWRkaXRpb25hbCBmYWN0cyBhbmQg bW90aXZhdGlvbnMuDQoNClRoZSBsYWNrIG9mIGNhbm9uaWNhbGl6ZWQgSlNPTiBoYXZlIGhhZCBx dWl0ZSBwcmFjdGljYWwgaW1wbGljYXRpb25zIGluIElFVEYgc2VjdXJpdHkgcHJvdG9jb2xzIGxp a2UgaW4gdGhpcyBvbmU6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXRlZXAtb3BlbnRydXN0cHJvdG9jb2wtMDINCg0KICAgICJUaGUgdG9wIGVsZW1lbnQgIjxuYW1l PltTaWduZWRdW1JlcXVlc3R8UmVzcG9uc2VdIiBjYW5ub3QgYmUgZnVsbHkNCiAgICAgdHJ1c3Rl ZCB0byBtYXRjaCB0aGUgY29udGVudCBiZWNhdXNlIGl0IGRvZXNuJ3QgcGFydGljaXBhdGUgaW4g dGhlDQogICAgIHNpZ25hdHVyZSBnZW5lcmF0aW9uLiAgSG93ZXZlciwgYSByZWNpcGllbnQgY2Fu IGFsd2F5cyBtYXRjaCBpdCB3aXRoDQogICAgIHRoZSB2YWx1ZSBhc3NvY2lhdGVkIHdpdGggdGhl IHByb3BlcnR5ICJwYXlsb2FkIi4gIEl0IHB1cmVseSBzZXJ2ZXMNCiAgICAgdG8gcHJvdmlkZSBh IHF1aWNrIHJlZmVyZW5jZSBmb3IgcmVhZGluZyBhbmQgbWV0aG9kIGludm9jYXRpb24iDQoNClRo YXQgaXMsIHRoZSBURUVQIGZvbGtzIHdlcmUgZm9yY2VkIGFkZGluZyBhIHJlZHVuZGFudCAoYW5k IElNTyBwcmV0dHkgdWdseSkgSlNPTiBsYXllciBpbiBvcmRlciB0byB0YWcgb2JqZWN0cyBzaW5j ZSB0aGUgSldTIHNpZ25hdHVyZSBzY2hlbWUgZHJlc3NlcyB0aGUgcGF5bG9hZCBpbiBCYXNlNjRV cmwuICBUaGlzIHNjaGVtZSBhbHNvIGludHJvZHVjZXMgYW4gYWRkaXRpb25hbCB2YWxpZGF0aW9u IHN0ZXAuDQoNClRoaXMgaXMgc29ydCBvZiB0aGUgb3Bwb3NpdGUgdG8gbXkgb3duIHdvcmsgaW4g dGhpcyBzcGFjZSwgd2hlcmUgY2Fub25pY2FsaXphdGlvbiBpcyBhbHNvIGFwcGxpZWQgdG8gdGhl IEpXUyBjb250YWluZXIgaXRzZWxmIChha2EgY2xlYXIgdGV4dCBzaWduYXR1cmVzKS4gIEhlcmUg YW4gZXhhbXBsZSBmcm9tICJTYXR1cm4iOg0KDQogICB7DQogICAgICAgInJlcXVlc3RIYXNoIjog ew0KICAgICAgICAgICAiYWxnIjogIlMyNTYiLA0KICAgICAgICAgICAidmFsIjogImNBLVFOZEpI Y3luanVNNDR0eS16WGdYd3gxMDBBWlZSRkxtWXgxU28wWGMiDQogICAgICAgfSwNCiAgICAgICAi ZG9tYWluTmFtZSI6ICJkZW1vbWVyY2hhbnQuY29tIiwNCiAgICAgICAicGF5bWVudE1ldGhvZCI6 ICJodHRwczovL2JhbmtkaXJlY3QubmV0IiwNCiAgICAgICAiYWNjb3VudElkIjogIjg2NDUtNzgw MDIzOTQwMyIsDQogICAgICAgInRpbWVTdGFtcCI6ICIyMDE5LTAzLTIzVDEwOjMzOjAyKzAxOjAw IiwNCiAgICAgICAic2lnbmF0dXJlIjogew0KICAgICAgICAgICAiYWxnIjogIkVTMjU2IiwNCiAg ICAgICAgICAgImp3ayI6IHsNCiAgICAgICAgICAgICAgICJrdHkiOiAiRUMiLA0KICAgICAgICAg ICAgICAgImNydiI6ICJQLTI1NiIsDQogICAgICAgICAgICAgICAieCI6ICJyUTRXWE1CNl93UUtI U2lZX21iSjRRa0dwZldMc3NGN2h2SWlpRnBERXg4IiwNCiAgICAgICAgICAgICAgICJ5IjogIkZo MnJsMExHVHR2YW9tT3VodVJObzlEcno5bzAtLVdYVjJJVHZkVlFGUlkiDQogICAgICAgICAgIH0s DQogICAgICAgICAgICJ2YWwiOiAiajJMTDlwcjJSeXJQeHZGbGo4SXpNaG5vNXZ2Z0dJZ2YyeGky M2RBNXVfWHdqWWxJdlQ5cXdJVkthQ0tZd2piMjZKNW1NVUw1elYwMmxxUUdqWlJDbHciDQogICAg ICAgfQ0KICB9DQoNClJlY2VudCBwcm9wb3NhbCBhZGRyZXNzaW5nIFNpZ25lZC9KU09OL1JFU1Qg c2luY2UgdGhpcyBhcHBhcmVudGx5IHN0aWxsIGlzIG1pc3Npbmc6DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtcnVuZGdyZW4tc2lnbmVkLWh0dHAtcmVxdWVzdHMtMDANCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL3NsaWRlcy0xMDQt aG90cmZjLTMtc2lnbmVkLWh0dHAtcmVxdWVzdHMtc2hyZXEtMDANCg0KQnJpbmcgeW91ciByb3R0 ZW4gdG9tYXRvZXMgaWYgeW91IHdhbnQgOi0pDQoNCkNoZWVycywNCkFuZGVycw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVEVFUCBtYWlsaW5nIGxp c3QNClRFRVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dGVlcA0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29w eSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Wed Mar 27 06:51:57 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692C212027C for ; Wed, 27 Mar 2019 06:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com 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 PO7ouNkUg3kw for ; Wed, 27 Mar 2019 06:51:45 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BC712000F for ; Wed, 27 Mar 2019 06:51:44 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id y13so987236wrd.3 for ; Wed, 27 Mar 2019 06:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AdRBcMVBqeH9FlBYPhArP6qvfI2GqCj3cIN0HStSh0c=; b=kAYqILXMB2MqASVy4OEVoAGRMfZojJsH8SXIkDIkQEGZdfv5V4+7yVuv4V1KHyjeKA To/ywIZoWI55MRL0ZUZJbCf7SzA4ha7NWA9iW5KTNKUchRWBIGHDbeH2jzlgUUX3KA79 bAGaxc+Aw+dCbB81W4CHXguHvnFXNt9OAGAjs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AdRBcMVBqeH9FlBYPhArP6qvfI2GqCj3cIN0HStSh0c=; b=VveN9yCZJoDS/KNQK76zY4vaT1ppVHPBzvuR7c4BLcoamRXs/rVFvs2BoqaGFs7T7L Zz6km5qymJ34Se29q4/s+z3x5K13RjX6FnI7aCDLS5lOxUycWvSN1egvGABstc1phL+J 24ReKokm3NwXC0zxHC/zpSb36kV3CC3tuSfUSQmm9hvD4CW9p98zLSlteUJXIMr7ZBWC kTKon5u6YtRGOL3qPdwe0m3JznSII8rmCYGwQ+ql9V9a1RJgKAsxOtE85nNNmtJwRZpo s4Vj+DGlvdptKyTHeBziWFDGBZbWX9sAefWIAmS+FDQkk5N08LtkYYssGeykOvr9FfV1 R/Bg== X-Gm-Message-State: APjAAAV8ABWp3BaZRYu1n62aEWuEDey6sEeQyOPezgt5bkwWx/VWC86G YcC04YWZe3COW96H/DxZFz3BqTfo8ZA= X-Google-Smtp-Source: APXvYqzrofr+cPU+OVSvqMYxkDsm5idfAHLuplw9aDlQaSE/LZHG97IRA9oRTWk5p8EoR+/4ZGoWwg== X-Received: by 2002:adf:9c91:: with SMTP id d17mr10683962wre.285.1553694703148; Wed, 27 Mar 2019 06:51:43 -0700 (PDT) Received: from guest2s-mbp.home.gateway (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id k14sm44290wmj.26.2019.03.27.06.51.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 06:51:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Neil Madden In-Reply-To: Date: Wed, 27 Mar 2019 13:51:40 +0000 Cc: IETF oauth WG Content-Transfer-Encoding: quoted-printable Message-Id: <3B27C5F4-3D67-4F37-9522-0883F0D18B85@forgerock.com> References: To: Vittorio Bertocci X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OAUTH-WG] JWT ATs and authenticated encryption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 13:51:49 -0000 Yes - a separate doc. Given that it is potentially useful in the context = of OAuth, it might be something that the OAuth WG could consider, given = that the JOSE WG is disbanded. I=E2=80=99ll see if I can find some time = to put a draft together. (In markdown now that my mind has been blown = that I don=E2=80=99t have to do everything in XML!) > On 26 Mar 2019, at 16:50, Vittorio Bertocci = wrote: >=20 > Hi Neil, > thanks! This does sound very interesting. Just to clarify, you would = document this in a separate doc extending JOSE? > We could then mention it from the JWT AT profile, whihc would remain = lightweight and implementation independent. > thanks > V. >=20 > On Tue, Mar 26, 2019 at 3:11 AM Neil Madden = wrote: > There was a brief discussion at OSW about signing vs encryption for = JWT-based access tokens. I think it was Brian Campbell that pointed out = that you often want authenticated encryption rather than signing, and I = agree with this. >=20 > Currently JOSE only supports authenticated encryption for symmetric = cryptography, which means that the AS and RS must agree a shared secret = key beforehand. (Or else the RS uses the token introspection endpoint = and doesn=E2=80=99t decrypt the token itself). Symmetric cryptography is = less than ideal when the AS and RS are in separate trust boundaries = (e.g., different companies). >=20 > There are actually ways to do *public key* authenticated encryption, = but JOSE doesn=E2=80=99t support them yet. I wrote a 3-part blog series = about this recently [1], but I=E2=80=99ll summarise the tl;dr version = here. I think for JWT-based access tokens that contain identity = assertions, this is probably what you want in most cases as it provides = both confidentiality and authenticity without needing a bulky nested = signed-then-encrypted JWT. Is this something people would be interested = in, if I propose a draft? >=20 > Details: >=20 > The basic idea is to introduce one or more variants on ECDH-ES that = provide sender authentication. The most straightforward is to use = ECDH-SS =E2=80=94 i.e., Diffie-Hellman between two static key pairs, one = for the sender and one for the recipient, with no ephemeral keys. This = provides authenticated encryption so long as the content encryption = method is authenticated (which they all are in JOSE). But it has a = number of security downsides, which I describe in more detail in the = blog. (It might be useful in some IoT scenarios though). >=20 > The better variant is to instead do ECDH-ESSS. That is, we generate a = random ephemeral key pair and do an agreement with the recipient=E2=80=99s= static public key, just like in ECDH-ES, but then we do another key = agreement between the sender=E2=80=99s static private key and the = recipient=E2=80=99s static private key. We then concatenate the two = shared secrets and feed them into ConcatKDF just like you would for = ECDH-ES. This is what NIST SP.800-56A [2] calls the =E2=80=9Cone-pass = unified model=E2=80=9D (section 6.2.1.2). If you squint a bit then it is = also very similar to the =E2=80=9CK=E2=80=9D one-way pattern in the = Noise protocol framework [3]. >=20 > To spell it out, the process for encrypting a JWE with this new scheme = is as follows: >=20 > Sender has long-term =E2=80=9Cstatic=E2=80=9D key pair: ssk,_spk (ssk = =3D sender secret key, etc) > Recipient has long-term static key pair: rsk, rpk >=20 > 1. Sender generates a random ephemeral key pair: esk, epk > 2. Calculate Ze :=3D ecdh(esk, rpk) =E2=80=94 just like in ECDH-ES > 3. Calculate Zs :=3D ecdh(ssk, rpk) > 4. Let Z =3D Ze || Zs where || is concatenation > 5. Run Z through ConcatKDF with PartyUInfo/PartyVInfo just as in = ECDH-ES > 6. Encrypt the message using the chosen =E2=80=9Cenc=E2=80=9D = encryption method using the key derived in step 5. >=20 > On its own ECDH-ESSS has some decent security properties (including = authenticated encryption), but it is especially good when you want to = exchange lots of messages with the recipient. If the recipient replies = to your initial message using ECDH-ESSS but using the ephemeral public = key you sent in the first message as if it was your static public key, = then what you get is an interactive handshake very similar to the Noise = KK pattern [4] (squinting quite hard at this point). Both parties can = then use the derived key from step 5 of the second message as a shared = session key and send =E2=80=9Cdirect=E2=80=9D encrypted JWEs to each = other from that point on. This provides very strong security properties = listed later in the Noise spec, including forward secrecy and both = sender and recipient authentication with resistance to key compromise = impersonation. So beyond its usefulness for Access Token JWTs, this = scheme is a really versatile building block that you can use for lots of = advanced use-cases (e.g., PoP schemes). >=20 > There are even nice formal models of the Noise handshake patterns in = ProVerif [5], but I think they are only valid for the specific details = of how Noise performs key derivation and transcript hashing so they = wouldn=E2=80=99t directly apply to a JOSE version. >=20 > [1] = https://neilmadden.blog/2018/11/14/public-key-authenticated-encryption-and= -why-you-want-it-part-i/ > [2] = https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pd= f > [3] https://noiseprotocol.org/noise.html#one-way-handshake-patterns=20 > [4] = https://noiseprotocol.org/noise.html#interactive-handshake-patterns-fundam= ental=20 > [5] https://noiseexplorer.com >=20 > Cheers, >=20 > Neil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Mar 27 06:57:49 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509DA12000F for ; Wed, 27 Mar 2019 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com 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 vKWP8W6SJ6vB for ; Wed, 27 Mar 2019 06:57:44 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CD1120004 for ; Wed, 27 Mar 2019 06:57:44 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id v4so14126180ioj.5 for ; Wed, 27 Mar 2019 06:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BWleDLnhgZxcEHuUGBUuzRTRyPCTCgeC0+zW+0qO4ww=; b=p6nVDF73HpI2G46UlSse1ucs6Z1oO37JaXiXY/SEMS/MJjgTITAN1wDskBWOZ7rQzM HTbWdp8xEEue1btYw8BoqL7bEZAI4uPXY9i2psDaNWk1O1XfLkFvyixv7xmCDojtiVPu bmPCvW9iIaPDWPAAONYvexeW/s1So5kLC0du/Af4CM7VZxSvr8EiF8hkF7P8ncWXg3ER X+7D40nUKmGq9GOZAAPQYDWKT+CyEn/GF8jsD9Qnw5hIrXCywg/ePOdaMmjrXoN5rl4f 0sEs1Jm+jF5nNCu59p4gFUyiya7tPbQH1BAOez3fC5HbUXQlOsEgLUmQjiJOZwGRRyaH 4y1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BWleDLnhgZxcEHuUGBUuzRTRyPCTCgeC0+zW+0qO4ww=; b=FYwlW2HHaidSjkb6kEpAuzNtfQoGPs/O4GvG0Gr0kDEtXcMaqE1wROgrwhY1hbFZim tgNRF4vPgCXGqvXQXWPHxaOXXI+06CBqVcy+20ren+jBNy/RlDCVLlmxqvZBbGPLGe0N d4N5vSOfO78F9llvJi34occKBhgfpc2vRvbSRiStDRoM3S3Ol2lu2PjeqjG1CPrQpX9a eNRkBgaCj3blh6vQXT39g3xQqOMDAL5ubYRaKp5qWni3Jv6TEfKCtaKzSE22CCJVXsk0 gdGcacC3GoyvhttMduI6h1FHjI+MJrACogzjFV10NfajdmUnB7+yytj4WZJwODFyEinM AZ4w== X-Gm-Message-State: APjAAAXub6c711tXTxB9rk9lJAHvGrSZR6WxcHJ2xvfB2mwUuM6YRVeM iwWrXXOqI+e8PkZ24Crv9vqADAa8C4m/ww== X-Google-Smtp-Source: APXvYqwq3LPLtWfF3QaSWCjDehBOhm62V5hV5kBtS4VcjhAtc+Qe0HIZPM3jy8k0gbQpzPGsXX1hvw== X-Received: by 2002:a6b:d307:: with SMTP id s7mr24877288iob.81.1553695063389; Wed, 27 Mar 2019 06:57:43 -0700 (PDT) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com. [209.85.166.49]) by smtp.gmail.com with ESMTPSA id b199sm31427itb.29.2019.03.27.06.57.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 06:57:42 -0700 (PDT) Received: by mail-io1-f49.google.com with SMTP id v4so14126091ioj.5 for ; Wed, 27 Mar 2019 06:57:42 -0700 (PDT) X-Received: by 2002:a6b:f90c:: with SMTP id j12mr721549iog.53.1553695062308; Wed, 27 Mar 2019 06:57:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Wed, 27 Mar 2019 13:57:30 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Torsten Lodderstedt Cc: Hannes Tschofenig , oauth Content-Type: multipart/alternative; boundary="0000000000004755b0058513d258" Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 13:57:48 -0000 --0000000000004755b0058513d258 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the thorough review, Torsten! I've made these changes to my working copy on GitHub but have not yet published an updated draft. My responses are inline below. For any of your points that don't have a response from me, I will address those separately but wanted to get this out with what I have. I've made notes about all the open questions based on this and other feedback, and we can discuss those at the workshop tomorrow. Thanks! On Tue, Dec 18, 2018 at 6:14 PM Torsten Lodderstedt wrote: > Hi Hannes, > > while I think the current text needs some substantial work, I support the > adoption of this draft as a working group document. I also think we need = to > carefully define the boundaries between the Security BCP and the SPA BCP = in > order to prevent unnecessary duplications and inconsistencies. > > Here are my review comments: > > "OAuth 2.0 authorization requests from apps running entirely in a > browser are unable to use a Client Secret during the process, since > they have no way to keep a secret confidential.=E2=80=9C > > Although I think that=E2=80=99s an important aspect I=E2=80=99m wondering= why the draft > starts with it? I don=E2=80=99t think this is the most important message.= If the > intend is to align with https://tools.ietf.org/html/rfc8252, I would > propose something like > > =E2=80=9EOAuth 2.0 authorization requests from browser based apps should = only be > made > using the code flow. =E2=80=A6" > Thanks, I agree that's a better introduction. I've updated accordingly. > > Section 3 > > "Browser-based application": An application that runs entirely in a > web browser, usually written in JavaScript, where the source code > is downloaded from a domain prior to execution. Also sometimes > referred to as a "single-page application", or "SPA=E2=80=9C. > > I think this definition is too narrow, which also limits applicability of > this draft. I would argue a browser based application runs portions of it= s > logic in the browser but not necessarily the entire app. Most browser bas= ed > apps have a backend in the same way as mobile apps have a backend. I thin= k > for the purpose of this draft the fact that the UI is controlled from > within the browser, uses browser APIs and underlies browser security > mechanisms & restrictions is much more important. Moreover, the source co= de > not even needs to be downloaded for every execution due to browser cachin= g. > > My proposal: > > "Browser-based application": An application that is dynamically > downloaded and executed in a web browser, usually written in > JavaScript. Also sometimes referred to as a "single-page > application", or "SPA=E2=80=9C. > > The thing I was trying to get at with this definition was that if you have a dynamic server-side component then you could do the OAuth flow from that component, keeping access tokens entirely out of the browser. This is clarified later in the document though, and I think your definition better summarizes what I was getting at anyway, so I've updated it accordingly. > Section 4 > > "Require the OAuth 2.0 state parameter" -> "Use the the state parameter t= o > carry one-time use CSRF tokens" > > Thanks, this is better. I do now have a question about this since the Security BCP is going to change to drop the recommendation of using the state parameter for CSRF protection. > "...require the > hostname of the redirect URI match the hostname of the URL the app > was served from=E2=80=9C > > Are we sure there are no legit reasons to receive the redirect at another > host? Is the AS supposed to determine the app's origin from the referrer > header? > Good question. I would love to hear from others if they have any deployments where a SPA launches the OAuth flow from one hostname but receives the redirect at another. > > "Previously it was recommended that browser-based applications use the > OAuth 2.0 Implicit flow. =E2=80=A6=E2=80=9C > > I suggest to mention broad adoption of CORS after publication of RFC 6749 > as reason why the shift towards code is possible now. > Agreed. I've adjusted that section. > > Section 5 > > =E2=80=9ETo conform to this best practice, first-party applications using > OAuth or OpenID Connect MUST use an OAuth Authorization Code flow as > described later in this document or use the OAuth Password grant." > > It does not feel well for me to read =E2=80=9EMUST" and "Password grant= =E2=80=9C in the > same sentence. I'm in favor to just recommend 1st party apps to use code > for reasons x, y, z and not mention password. > I'm all for dropping the password grant too, but that feels like a bigger decision. If the Security BCP is going to make any recommendations around that I could reference those here. But if this document is going to disallow the password grant then it would need a lot more background information about why added to the document. > > I also think the arguments are more dominante when formatted as bullet > list. > > Section 6 > > "In some cases, it may make sense to avoid the use of a strictly > browser-based OAuth application entirely, instead using an > architecture that can provide better security.=E2=80=9C > > Reads like OAuth implies degraded app security? > Thanks, that was poorly worded. I've updated it to this: "In some cases, it may make sense to avoid the use of a strictly browser-based OAuth application entirely, and instead use an architecture that keeps OAuth access tokens out of the browser." Does that clarify it? > > 6.1. > > =E2=80=9EFor simple system architectures, such as when the JavaScript > application is served from the same domain as the API (resource > server) being accessed, it is likely a better decision to avoid using > OAuth entirely, and just use session authentication to communicate > with the API.=E2=80=9C > > What do you mean by same domain? same second level domain? same host? I'm > not sure what this text want to convey. > This is about the idea that if you can share a cookie between the JavaScript app and the API being accessed, then you may not need OAuth at all and can use something like a common session. Does this text clarify that? "For simple system architectures, such as when the JavaScript application is served from a domain that can share cookies with the API's (resource server's) domain, it is likely a better decision to avoid using OAuth entirely, and just use session authentication to communicate with the API." > > Section 6.2. > > 2nd paragraph =E2=80=9E=E2=80=A6.The backend component essentially become= s a new > authorization server=E2=80=9C > > I get the message, but the term "authorization server" misled me when I > read the text for the first time. I was under the impression, your are > proposing OAuth as communication protocol between an app's front and > backend. This is possible but just one option. I suggest to remove the > term. It does not really help. > Agreed, thanks. > > 3rd paragraph =E2=80=9EIn this scenario, the backend component may be a > confidential client > which is issued its own client secret. =E2=80=9E > > Confidential clients can use various authentication methods, =E2=80=9Esec= ret" > misleads reader towards traditional client secrets. private_key_jwt and > mTLS are possible (and better options). > I've changed that sentence to: "In this scenario, the backend component may be a confidential client which has the ability to authenticate itself" > > =E2=80=9EDespite this, there are still > some ways in which this application is effectively a public client, > as the end result is the application's code is still running in the > browser and visible to the user.=E2=80=9C > > Why does this make the SPA a public client? I see the risk of a browser > based app (and every kind of attacker) to access protected APIs through t= he > backend. That's the reason why I think the backend should never directly > expose (=3D=3D just proxy) the underlying RS APIs. The interface between = front > and backend must be narrowed down to the specific use case AND the curren= t > state of the app. For example, if the app is in "check out" state it make= s > sense to initiate a payment but in no other state. > I think you've described the attack I was getting at here. If this backend component is just proxying API requests, then those requests can still be triggered by malicious code. Do you think it's worth rewording this section to describe that particular scenario instead? > > General remark: I would suggest to restructure section 6 to describe the > potential architectures this BCP has in mind. From my perspective these a= re: > - "pure" SPA > - SPA w/ backend > - SPA w/o OAuth (as fallback) > > There are only two headers in section 6 right now, the "SPA w/backend" an= d "SPA w/o OAuth" scenarios. The rest of the document describes the "pure SPA" use case. Would it make sense to include a header in this section that essentially states that? > Section 7.1 > > =E2=80=9EPublic browser-based apps MUST implement the Proof Key for Code = extension > to OAuth, and authorization > servers MUST support PKCE for such clients." > > Any client MUST use PKCE (see Security BCP) - PKCE is used beyond > interception prevention to detect injection. Please refer to section 2.1 = of > the security BCP it has all the details. > > I'm not sure what your suggestion here is. Do you mean that the document should not describe the potential attack and instead reference the security BCP instead? > Section 7.2 > > =E2=80=9EAuthorization servers SHOULD require an exact match of a registe= red > redirect URI." > > Please make it a MUST as stated in the Security BCP, Section 2.1 > > =E2=80=9E If an authorization server wishes to provide some flexibility = in > redirect URI usage to clients, it MAY require that only the hostname > component of the redirect URI match the hostname of the URL the > application is served from.=E2=80=9C > > Why do you soften the Security BCP requirements? That's the road to open > redirection! > I believe this came up in the original discussion of this topic at IIW in October. I don't remember the state of the security BCP at that point, and I don't remember who it was that was asking for this. I agree it probably makes more sense to not make this allowance here and instead require an exact match. We should discuss this further to find out if anyone has strong feelings on this. > > Section 8 > > This section lacks a motivation for RT usage. In my opinion, there are tw= o > reasons: > (1) use RTs instead of refresh via authorization code flow (to cope with > ITP2). > (2) be able to issue short lived and privilege restricted access tokens i= n > order to limit the impact of access token leakage at resource servers. > > Both are good reasons that deserve dedicated discussions. I therefore > suggest to split & change Section 8 into two sections, =E2=80=9EAccess To= ken > Refresh" and =E2=80=9EAccess Token Replay Mitigation". > > The section on access token mitigation should discuss potential options, > including > - Token Binding > - mTLS > - RT rotation > Are these topics and background not already covered in the security BCP? I thought there was a fair amount of discussion there around refresh tokens. My intent with this document was to provide two options for refresh tokens in browser based apps: 1) browser based apps SHOULD NOT be issued refresh tokens 2) if the AS does issue refresh tokens, then the AS MUST issue a new RT with every RT request. > =E2=80=A6 > > Section 9.1 > > This BCP describes different SPA design where such apps can be either > public or confidential. So I would not preclude confidential clients. > Most of the document is talking about the pure-JS app case, which was the intent of requiring registering those as public clients. If the JS app has a backend component then it's no longer a pure JS app, and most of these recommendations don't apply. I think I'm getting a sense that the scope of this document is not clearly enough defined. > > Section 9.4 > > You might want to refer to the Security BCP as it has more details on thi= s > topic. > > I would also suggest to add use of CORS for CSRF protection in the browse= r > (see https://www.ietf.org/mail-archive/web/oauth/current/msg18591.html) > since it is SPA specific. > > Section 9.6. > > I would argue enabling CORS is not a security consideration but a > functional requirement towards the AS. > > 2nd paragraph > > CORS and authorization of GET&POST requests plays a vital role in CSRF > prevention if the access tokens are conveyed in a cookie as well as for a= ny > automatic way to add authorization headers to outbound requests (see > above). So I think it must be managed properly. > > Section 9.7 > > Why do you bind CSP to RTs or long living access tokens. Isn=E2=80=99t th= is anyway > a good idea to prevent XSS? > > Section 9.8.6 > > injection is neglected - I think you could just refer to the Security BCP > for the discussion of the risks associated with implicit. If any threat i= s > missing there, we can add it there. > I do think it's worth calling out the disadvantages of the implicit flow somehow in this document, even if it's just a short summary that links out to the security BCP for the full details. Should I try to remove some language from this section to trim it down and then link out to the security BCP? > > =E2=80=9EIn OpenID Connect, =E2=80=A6=E2=80=9C > > Not clear to me what this text shall convey. Is it a statement in favor o= f > issuing id tokens in the back channel in OIDC? > Yes that was the intent, but maybe that's confusing since this document is supposed to be about OAuth 2.0 only? Should I remove that paragraph? > > Section 9.8.7 > > I would put this text in a motivation section along with the explanation > why CORS adoption allows code adoption for SPAs in the introduction of th= e > BCP. > Agreed, I've moved it to the overview section. > > kind regards, > Torsten. > > > > Am 17.12.2018 um 22:01 schrieb Hannes Tschofenig < > Hannes.Tschofenig@arm.com>: > > > > Hi all, > > > > We would like to get a confirmation on the mailing list for the adoptio= n > of https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02 > as a starting point for a BCP document about *OAuth 2.0 for Browser-Based > Apps*. > > > > Please, let us know if you support or object to the adoption of this > document by Jan. 7th 2019. > > > > Ciao > > Hannes & Rifaat > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000004755b0058513d258 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thank you for the = thorough review, Torsten! I've made these changes to my working copy on= GitHub but have not yet published an updated draft. My responses are inlin= e below. For any of your points that don't have a response from me, I w= ill address those separately but wanted to get this out with what I have.

    I've made notes about a= ll the open questions based on this and other feedback, and we can discuss = those at the workshop tomorrow.

    Thanks!


    On Tue, Dec 18, 2018 at 6:14 PM Torsten Lod= derstedt <torsten@lodderstedt= .net> wrote:
    Hi Hannes,

    while I think the current text needs some substantial work, I support t= he adoption of this draft as a working group document. I also think we need= to carefully define the boundaries between the Security BCP and the SPA BC= P in order to prevent unnecessary duplications and inconsistencies.

    Here are my review comments:

    "OAuth 2.0 authorization requests from apps running entirely in a<= br>=C2=A0 =C2=A0browser are unable to use a Client Secret during the proces= s, since
    =C2=A0 =C2=A0they have no way to keep a secret confidential.=E2= =80=9C

    Although I think that=E2=80=99s an important aspect I=E2=80=99m wonderi= ng why the draft starts with it? I don=E2=80=99t think this is the most imp= ortant message. If the intend is to align with https://tools.ietf= .org/html/rfc8252, I would propose something like

    =E2=80=9EOAuth 2.0 authorization requests from browser based apps shoul= d only be made
    =C2=A0 =C2=A0using the code flow. =E2=80=A6"

    Thanks, I agree that's a better introducti= on. I've updated accordingly.
    =C2=A0

    Section 3

    "Browser-based application":=C2=A0 An application that runs e= ntirely in a
    =C2=A0 =C2=A0 =C2=A0 web browser, usually written in JavaSc= ript, where the source code
    =C2=A0 =C2=A0 =C2=A0 is downloaded from a do= main prior to execution.=C2=A0 Also sometimes
    =C2=A0 =C2=A0 =C2=A0 refer= red to as a "single-page application", or "SPA=E2=80=9C.

    I think this definition is too narrow, which also limits applicability = of this draft. I would argue a browser based application runs portions of i= ts logic in the browser but not necessarily the entire app. Most browser ba= sed apps have a backend in the same way as mobile apps have a backend. I th= ink for the purpose of this draft the fact that the UI is controlled from w= ithin the browser, uses browser APIs and underlies browser security mechani= sms & restrictions is much more important. Moreover, the source code no= t even needs to be downloaded for every execution due to browser caching. <= br>
    My proposal:

    "Browser-based application":=C2=A0 An application that is dyn= amically
    =C2=A0 =C2=A0 =C2=A0 downloaded and executed in a web browser,= usually written in
    =C2=A0 =C2=A0 =C2=A0JavaScript. Also sometimes refe= rred to as a "single-page application", or "SPA=E2=80=9C.

    The thing I was trying to get at = with this definition was that if you have a dynamic server-side component t= hen you could do the OAuth flow from that component, keeping access tokens = entirely out of the browser. This is clarified later in the document though= , and I think your definition better summarizes what I was getting at anywa= y, so I've updated it accordingly.

    =C2= =A0
    Section 4

    "Require the OAuth 2.0 state parameter" -> "Use the t= he state parameter to carry one-time use CSRF tokens"

    Thanks, this is better. I do now have a question abou= t this since the Security BCP is going to change to drop the recommendation= of using the state parameter for CSRF protection.

    =C2=A0
    "...req= uire the
    =C2=A0 =C2=A0 =C2=A0 hostname of the redirect URI match the hos= tname of the URL the app
    =C2=A0 =C2=A0 =C2=A0 was served from=E2=80=9C <= br>
    Are we sure there are no legit reasons to receive the redirect at anoth= er host? Is the AS supposed to determine the app's origin from the refe= rrer header?
    Good question. I would love to hear from = others if they have any deployments where a SPA launches the OAuth flow fro= m one hostname but receives the redirect at another.=C2=A0
    =C2=A0=

    "Previously it was recommended that browser-based applications use= the
    =C2=A0 =C2=A0OAuth 2.0 Implicit flow. =E2=80=A6=E2=80=9C

    I suggest to mention broad adoption of CORS after publication of RFC 67= 49 as reason why the shift towards code is possible now.

    Agreed. I've adjusted that section.
    =C2=A0<= /div>

    Section 5

    =E2=80=9ETo conform to this best practice, first-party applications usi= ng
    =C2=A0 =C2=A0OAuth or OpenID Connect MUST use an OAuth Authorization = Code flow as
    =C2=A0 =C2=A0described later in this document or use the OA= uth Password grant."

    It does not feel well for me to read =E2=80=9EMUST" and "Pass= word grant=E2=80=9C in the same sentence. I'm in favor to just recommen= d 1st party apps to use code for reasons x, y, z and not mention password.<= br>

    I'm all for dropping the password g= rant too, but that feels like a bigger decision. If the Security BCP is goi= ng to make any recommendations around that I could reference those here. Bu= t if this document is going to disallow the password grant then it would ne= ed a lot more background information about why added to the document.
    =
    =C2=A0

    I also think the arguments are more dominante when formatted as bullet = list.

    Section 6

    "In some cases, it may make sense to avoid the use of a strictly=C2=A0 =C2=A0browser-based OAuth application entirely, instead using an=C2=A0 =C2=A0architecture that can provide better security.=E2=80=9C

    Reads like OAuth implies degraded app security?
    Thanks, that was poorly worded. I've updated it to this:

    "In some cases, it may make sense to avoid the= use of a strictly browser-based OAuth
    application entirely, and = instead use an architecture that keeps OAuth access tokens
    out of= the browser."

    Does that clarify it?
    =C2=A0

    6.1.

    =E2=80=9EFor simple system architectures, such as when the JavaScript=C2=A0 =C2=A0application is served from the same domain as the API (resou= rce
    =C2=A0 =C2=A0server) being accessed, it is likely a better decision = to avoid using
    =C2=A0 =C2=A0OAuth entirely, and just use session authent= ication to communicate
    =C2=A0 =C2=A0with the API.=E2=80=9C

    What do you mean by same domain? same second level domain? same host? I= 'm not sure what this text want to convey.

    This is about the idea that if you can share a cookie between the J= avaScript app and the API being accessed, then you may not need OAuth at al= l and can use something like a common session. Does this text clarify that?=

    "For simple system architectures, such as wh= en the JavaScript application is served
    from a domain that can sh= are cookies with the API's (resource server's) domain, it=C2=A0
    is likely a better decision to avoid using OAuth entirely, and just = use session=C2=A0
    authentication to communicate with the API.&quo= t;

    =C2=A0

    Section 6.2.

    2nd paragraph =E2=80=9E=E2=80=A6.The backend component essentially beco= mes a new authorization server=E2=80=9C

    I get the message, but the term "authorization server" misled= me when I read the text for the first time. I was under the impression, yo= ur are proposing OAuth as communication protocol between an app's front= and backend. This is possible but just one option. I suggest to remove the= term. It does not really help.

    Agreed,= thanks.
    =C2=A0

    3rd paragraph =E2=80=9EIn this scenario, the backend component may be a= confidential client
    =C2=A0 =C2=A0which is issued its own client secret.= =E2=80=9E

    Confidential clients can use various authentication methods, =E2=80=9Es= ecret" misleads reader towards traditional client secrets. private_key= _jwt and mTLS are possible (and better options).

    =
    I've changed that sentence to: "In this scenario, the b= ackend component may be a confidential client which has the ability to auth= enticate itself"
    =C2=A0

    =E2=80=9EDespite this, there are still
    =C2=A0 =C2=A0some ways in whi= ch this application is effectively a public client,
    =C2=A0 =C2=A0as the = end result is the application's code is still running in the
    =C2=A0 = =C2=A0browser and visible to the user.=E2=80=9C

    Why does this make the SPA a public client? I see the risk of a browser= based app (and every kind of attacker) to access protected APIs through th= e backend. That's the reason why I think the backend should never direc= tly expose (=3D=3D just proxy) the underlying RS APIs. The interface betwee= n front and backend must be narrowed down to the specific use case AND the = current state of the app. For example, if the app is in "check out&quo= t; state it makes sense to initiate a payment but in no other state.=C2=A0 =

    I think you've described the attac= k I was getting at here. If this backend component is just proxying API req= uests, then those requests can still be triggered by malicious code. Do you= think it's worth rewording this section to describe that particular sc= enario instead?
    =C2=A0

    General remark: I would suggest to restructure section 6 to describe th= e potential architectures this BCP has in mind. From my perspective these a= re:
    - "pure" SPA
    - SPA w/ backend
    - SPA w/o OAuth (as fa= llback)

    There are only two headers in section 6 right now, th= e "SPA w/backend" and "SPA w/o OAuth" scenarios. The re= st of the document describes the "pure SPA" use case. Would it ma= ke sense to include a header in this section that essentially states that?<= /div>

    =C2=A0
    Section 7.1

    =E2=80=9EPublic browser-based apps MUST implement the Proof Key for Cod= e extension to OAuth, and authorization
    =C2=A0 =C2=A0servers MUST suppor= t PKCE for such clients."

    Any client MUST use PKCE (see Security BCP) - PKCE is used beyond inter= ception prevention to detect injection. Please refer to section 2.1 of the = security BCP it has all the details.

    I'm not sure what your suggestion here is. Do you= mean that the document should not describe the potential attack and instea= d reference the security BCP instead?

    =C2=A0
    =
    Section 7.2

    =E2=80=9EAuthorization servers SHOULD require an exact match of a regis= tered
    =C2=A0 =C2=A0redirect URI."

    Please make it a MUST as stated in the Security BCP, Section 2.1

    =E2=80=9E=C2=A0 If an authorization server wishes to provide some flexi= bility in
    =C2=A0 =C2=A0redirect URI usage to clients, it MAY require tha= t only the hostname
    =C2=A0 =C2=A0component of the redirect URI match the= hostname of the URL the
    =C2=A0 =C2=A0application is served from.=E2=80= =9C

    Why do you soften the Security BCP requirements? That's the road to= open redirection!

    I believe this came = up in the original discussion of this topic at IIW in October. I don't = remember the state of the security BCP at that point, and I don't remem= ber who it was that was asking for this. I agree it probably makes more sen= se to not make this allowance here and instead require an exact match. We s= hould discuss this further to find out if anyone has strong feelings on thi= s.
    =C2=A0

    Section 8

    This section lacks a motivation for RT usage. In my opinion, there are = two reasons:
    (1) use RTs instead of refresh via authorization code flow= (to cope with ITP2).
    (2) be able to issue short lived and privilege re= stricted access tokens in order to limit the impact of access token leakage= at resource servers.

    Both are good reasons that deserve dedicated discussions. I therefore s= uggest to split & change Section 8 into two sections, =E2=80=9EAccess T= oken Refresh" and =E2=80=9EAccess Token Replay Mitigation".

    The section on access token mitigation should discuss potential options= , including
    - Token Binding
    - mTLS
    - RT rotation
    =C2=A0
    Are these topics and background not already covered = in the security BCP? I thought there was a fair amount of discussion there = around refresh tokens. My intent with this document was to provide two opti= ons for refresh tokens in browser based apps:=C2=A0

    1) browser based apps SHOULD NOT be issued refresh tokens
    2) if= the AS does issue refresh tokens, then the AS MUST issue a new RT with eve= ry RT request.

    =C2=A0
    =E2=80=A6

    Section 9.1

    This BCP describes different SPA design where such apps can be either p= ublic or confidential. So I would not preclude confidential clients.

    Most of the document is talking about the pur= e-JS app case, which was the intent of requiring registering those as publi= c clients. If the JS app has a backend component then it's no longer a = pure JS app, and most of these recommendations don't apply. I think I&#= 39;m getting a sense that the scope of this document is not clearly enough = defined.=C2=A0
    =C2=A0

    Section 9.4

    You might want to refer to the Security BCP as it has more details on t= his topic.

    I would also suggest to add use of CORS for CSRF protection in the brow= ser (see https://www.ietf.org/mail-= archive/web/oauth/current/msg18591.html) since it is SPA specific.

    Section 9.6.

    I would argue enabling CORS is not a security consideration but a funct= ional requirement towards the AS.

    2nd paragraph

    CORS and authorization of GET&POST requests plays a vital role in C= SRF prevention if the access tokens are conveyed in a cookie as well as for= any automatic way to add authorization headers to outbound requests (see a= bove). So I think it must be managed properly.

    Section 9.7

    Why do you bind CSP to RTs or long living access tokens. Isn=E2=80=99t = this anyway a good idea to prevent XSS?

    Section 9.8.6

    injection is neglected - I think you could just refer to the Security B= CP for the discussion of the risks associated with implicit. If any threat = is missing there, we can add it there.

    I do think it's worth calling out the disadvantages of the implicit fl= ow somehow in this document, even if it's just a short summary that lin= ks out to the security BCP for the full details. Should I try to remove som= e language from this section to trim it down and then link out to the secur= ity BCP?

    =C2=A0

    =E2=80=9EIn OpenID Connect, =E2=80=A6=E2=80=9C

    Not clear to me what this text shall convey. Is it a statement in favor= of issuing id tokens in the back channel in OIDC?
    Yes that was the intent, but maybe that's confusing since t= his document is supposed to be about OAuth 2.0 only? Should I remove that p= aragraph?
    =C2=A0

    Section 9.8.7

    I would put this text in a motivation section along with the explanatio= n why CORS adoption allows code adoption for SPAs in the introduction of th= e BCP.

    Agreed, I've moved it to the= overview section.
    =C2=A0

    kind regards,
    Torsten.


    > Am 17.12.2018 um 22:01 schrieb Hannes Tschofenig <Hannes.Tschofenig@arm.com= >:
    >
    > Hi all,
    >
    > We would like to get a = confirmation on the mailing list for the adoption of https://tools.ietf.org/html/draft-parecki-oauth-brows= er-based-apps-02 as a starting point for a BCP document about *OAuth 2.= 0 for Browser-Based Apps*.
    >
    > Please, let us know if you supp= ort or object to the adoption of this document by Jan. 7th 2019.
    > > Ciao
    > Hannes & Rifaat
    > IMPORTANT NOTICE: The conte= nts of this email and any attachments are confidential and may also be priv= ileged. If you are not the intended recipient, please notify the sender imm= ediately and do not disclose the contents to any other person, use it for a= ny purpose, or store or copy the information in any medium. Thank you.
    &= gt;
    > _______________________________________________
    > OAuth = mailing list
    > OA= uth@ietf.org
    > https://www.ietf.org/mailman/lis= tinfo/oauth

    _______________________________________________
    OAuth mailing list OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --0000000000004755b0058513d258-- From nobody Wed Mar 27 09:13:38 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A767A1202F9 for ; Wed, 27 Mar 2019 09:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 gwXBALvE51oC for ; Wed, 27 Mar 2019 09:13:33 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30052.outbound.protection.outlook.com [40.107.3.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C667C120283 for ; Wed, 27 Mar 2019 09:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3RLXU49OgsNaffMKClaiT/Rn1iKgP+/kBdu818SXzLs=; b=V6xLu/ZCE0ZzgNwL3YE1u2sTPZH4ECpF5JBzCSngkyRNI3lYdzI//oZ2mDU2YnKYMoPgT1gtYRquCPgfp6cOPo+9+1azQ780WF+hIU3Q+1PbariP5/WfNgr+P2nnBB3QESy9tG+X8EjBfD7I4QOj7ct6183L01gxA/zB6s2JWe4= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1757.eurprd08.prod.outlook.com (10.168.67.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Wed, 27 Mar 2019 16:13:30 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65%11]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 16:13:30 +0000 From: Hannes Tschofenig To: "Manger, James" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.txt Thread-Index: AQHU2A+bcK5wMmkUTUiF+/Hyb6gv0aYHefmAgBg7hMA= Date: Wed, 27 Mar 2019 16:13:30 +0000 Message-ID: References: <155231144978.23050.17841259546883608773@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [2001:67c:1232:144:b4fd:f594:f317:4fcb] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2d4279d7-68b4-4169-7ef0-08d6b2cf272a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1757; x-ms-traffictypediagnostic: VI1PR0801MB1757: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-forefront-prvs: 0989A7979C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(396003)(346002)(376002)(40434004)(199004)(189003)(13464003)(51914003)(25786009)(52536014)(2906002)(71200400001)(2501003)(97736004)(33656002)(105586002)(71190400001)(66574012)(106356001)(68736007)(5660300002)(186003)(7736002)(305945005)(110136005)(6246003)(256004)(6116002)(14444005)(966005)(53936002)(5024004)(6306002)(55016002)(72206003)(8676002)(6506007)(102836004)(316002)(6436002)(53546011)(81166006)(76176011)(81156014)(99286004)(11346002)(446003)(8936002)(476003)(9686003)(46003)(86362001)(478600001)(14454004)(74316002)(486006)(7696005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1757; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: fh9Swr7+8KpvbuHa5qLc74p0BccyjlGHC6SIsm4GWz8URvD3Rw/tHgrt2a+++bFE3Cy7Tv7gO5gxtAqkNBMpIAhXCgatOGwQoNlEkl3pietytFnSuxj9s0TizEhu1PZ0sbESMboY1d0jRyeveXsUiJoGC4nTgr1ZIZLTO/QHpilmD/2Vj4xWVuhd7ir6iE7Fhusb2sDhs00+Wya7XBXae6IPZF6ry7hANRkHUIP76mx4rnClcjg9IMt5hnUcRSwSKP8TRfuctv4Yr2kbl4wOvt6luzhcNtvwJfUz+eErU4rAjE30oQp0NnD9hlmWDhAymi0CM0ZKAt+BfFGCdguDwvw484UND2b07CAsfSiUdIgHqs4TlQEwfatdmQS23r9Afye1seE56z2RcrN5fO5qugEJEuONNPfEii9W8YN/+Fk= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d4279d7-68b4-4169-7ef0-08d6b2cf272a X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 16:13:30.2923 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1757 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 16:13:37 -0000 Thanks for the review comments, James. I have just worked on a draft update and incorporated your suggestions. I w= ill submit draft -07 in time for the OAuth WG session tomorrow. Ciao Hannes -----Original Message----- From: OAuth On Behalf Of Manger, James Sent: Dienstag, 12. M=E4rz 2019 06:33 To: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-0= 6.txt Syntax glitches in draft-ietf-oauth-pop-key-distribution-06: 1. "exp" and "nbf" values should be numbers, not strings, so must not have = quotes [Section 4.2.2. "Client-to-AS Response"] 2. h'11' and b64'...' appear in the JSON examples, but should be "..." stri= ngs [Section 4.2.2. "Client-to-AS Response", members "kid", "x", "y"] 3. "iss" should be an https URI, such as "https://server.example.com", not = "xas.example.com" [Section 4.2.2. "Client-to-AS Response"]. "aud" should pr= obably be https://... as well, not http://.... -- James Manger -----Original Message----- From: OAuth On Behalf Of internet-drafts@ietf.org Sent: Tuesday, 12 March 2019 12:37 AM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Proof-of-Possession: Authorization Serv= er to Client Key Distribution Authors : John Bradley Phil Hunt Michael B. Jones Hannes Tschofenig Mihaly Meszaros Filename : draft-ietf-oauth-pop-key-distribution-06.txt Pages : 17 Date : 2019-03-11 Abstract: RFC 6750 specified the bearer token concept for securing access to protected resources. Bearer tokens need to be protected in transit as well as at rest. When a client requests access to a protected resource it hands-over the bearer token to the resource server. The OAuth 2.0 Proof-of-Possession security concept extends bearer token security and requires the client to demonstrate possession of a key when accessing a protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-06 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution= -06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-key-distribution-0= 6 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Mar 27 10:51:13 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8AB12031D; Wed, 27 Mar 2019 10:51:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <155370906384.10323.9697879195759951398@ietfa.amsl.com> Date: Wed, 27 Mar 2019 10:51:03 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 17:51:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution Authors : John Bradley Phil Hunt Michael B. Jones Hannes Tschofenig Mihaly Meszaros Filename : draft-ietf-oauth-pop-key-distribution-07.txt Pages : 17 Date : 2019-03-27 Abstract: RFC 6750 specified the bearer token concept for securing access to protected resources. Bearer tokens need to be protected in transit as well as at rest. When a client requests access to a protected resource it hands-over the bearer token to the resource server. The OAuth 2.0 Proof-of-Possession security concept extends bearer token security and requires the client to demonstrate possession of a key when accessing a protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 27 12:51:10 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0250120325; Wed, 27 Mar 2019 12:51:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <155371626071.10418.4550028833628276340@ietfa.amsl.com> Date: Wed, 27 Mar 2019 12:51:00 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 19:51:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 for Browser-Based Apps Authors : Aaron Parecki David Waite Filename : draft-ietf-oauth-browser-based-apps-01.txt Pages : 15 Date : 2019-03-27 Abstract: OAuth 2.0 authorization requests from browser-based apps must be made using the authorization code grant with the PKCE extension, and should not be issued a client secret when registered. This specification details the security considerations that must be taken into account when developing browser-based applications, as well as best practices for how they can securely implement OAuth 2.0. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-browser-based-apps-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 28 03:17:22 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCB0120482 for ; Thu, 28 Mar 2019 03:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yes.com 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 T13EOPsqpA8m for ; Thu, 28 Mar 2019 03:17:08 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1412B120264 for ; Thu, 28 Mar 2019 03:17:08 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id w10so22123017wrm.4 for ; Thu, 28 Mar 2019 03:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yes.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=ZwE4nmtFY6XQ2Q751uZVIlWEHAqbLKqrSJ2NxfOliHE=; b=Yp8sbAy/xRLuRdX4HurizbXF4iX9GTfjHet8d+OP328hv6wZbOwA005VMBfG0STnQl ZXwbRMeorSgOJb2szejXSQ8L0lGdPLAhjCRbjmHHABTo4U2oU4VFPkxsY3rB+SrK+1gI rZZ6hp0ZtJomXwMRM3K1hZg6zbeOLbM6zNtlTitQLCT9CNVWlxeujatMgTa9/UqmGaPg NcYpCIgAuA4fHX37x+qKAu5TuwWl3ZA4Pyc9v1d2GFXFpJnxjrqSLXbT5100kT10zdiw UGmGGPIu4KpHxKNJ9FzZ0fP9WDiCyiu/S3WvOj8AduHoApQqf31T+nCXz1/ivLDicHPE 1aWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=ZwE4nmtFY6XQ2Q751uZVIlWEHAqbLKqrSJ2NxfOliHE=; b=XIjq+5gIZciul/BDKiRJvDHyxU1ncEYUEp+y/MkX15rVHZ5WzjoRHCWJS2LCdD6HZh 2fzKYS+laD1SjxjUKmh2Gu4A15Flmq3t5tsQ8t6Rrwgge9ybeMqMUP47GVx721ggFUmf Y8SW7nHUpPiqL2q3CAm+OSAfXo/glX1vY45CTWipDLlNxJ77S6pgtVYhy1UFolVGntcX Zdb8Ku8cZnAei3dIKXDL81TbL2tyUROBW4ktxO3GJTk6z7QF8A3BDrcc7wwIlTQzby9k lVkvaFvrCyo68/Gxt0q7I9QQD8Qt6bYgk+xGCmMKS9AZHuzjDVhoBWeX5NYQPIj+Ponx NWXw== X-Gm-Message-State: APjAAAUY/BSlj7GXUxN2UitkkD0m020wJiKzHIExKwfiHWFug/ZXWw8p og3c0Gapp601WhRHyjYB0nWJMrAFqm+jkg== X-Google-Smtp-Source: APXvYqybXzHVyEoM6Ld1g/3xilOxJnjljDcucGBtQkGbXPZrI/Mr0a5THc5nEJmTf4S+7UVPb4iPZg== X-Received: by 2002:adf:e50d:: with SMTP id j13mr26529237wrm.165.1553768226016; Thu, 28 Mar 2019 03:17:06 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:f1b3:d98b:e97d:978b? ([2001:67c:1232:144:f1b3:d98b:e97d:978b]) by smtp.gmail.com with ESMTPSA id j1sm3356250wme.4.2019.03.28.03.17.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 03:17:05 -0700 (PDT) To: oauth@ietf.org From: Daniel Fett Message-ID: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> Date: Thu, 28 Mar 2019 11:17:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C88AE1ACA1CDA2F5026DCEA4" Content-Language: de-DE Archived-At: Subject: [OAUTH-WG] draft-fett-oauth-dpop-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 10:17:21 -0000 This is a multi-part message in MIME format. --------------C88AE1ACA1CDA2F5026DCEA4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all, I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00 Abstract This document defines a sender-constraint mechanism for OAuth 2.0 access tokens and refresh tokens utilizing an application-level proof-of-possession mechanism based on public/private key pairs. Thanks for the feedback I received so far from John, Mike, Torsten, and others during today's session or before! If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop - Daniel    --------------C88AE1ACA1CDA2F5026DCEA4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Hi all,

    I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00

    Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.

    Thanks for the feedback I received so far from John, Mike, Torsten, and others during today's session or before!

    If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop

    - Daniel   

    --------------C88AE1ACA1CDA2F5026DCEA4-- From nobody Thu Mar 28 03:36:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E2D120474 for ; Thu, 28 Mar 2019 03:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 hJBm3m_q5Qpw for ; Thu, 28 Mar 2019 03:36:02 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C0FEE12044C for ; Thu, 28 Mar 2019 03:36:01 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2SAZu7K008189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Mar 2019 06:35:58 -0400 Date: Thu, 28 Mar 2019 05:35:56 -0500 From: Benjamin Kaduk To: Mike Jones Cc: "oauth@ietf.org" , Pamela Dingle Message-ID: <20190328103555.GL67070@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-signed-http-request-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 10:36:11 -0000 Hi Mike, Thanks for doing this review; just to confirm one point... On Tue, Mar 26, 2019 at 02:35:47PM +0000, Mike Jones wrote: > > 3. "Note to WG" - I suspect that this wouldn't get past the IESG without crypto agility. A parameter probably needs to be introduced to specify the hash algorithm used - with the default being SHA-256 if omitted. I don't have to suspect this; I am confident that it would not. See also BCP 201. -Ben From nobody Thu Mar 28 04:05:41 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBEC120487 for ; Thu, 28 Mar 2019 04:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com 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 DVGQtpTBbHeL for ; Thu, 28 Mar 2019 04:05:27 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30086.outbound.protection.outlook.com [40.107.3.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C466120289 for ; Thu, 28 Mar 2019 04:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aWzkQ5QFJdWUBaD//lGvr8hxdggQkdBxNAl+OgsehPU=; b=AN7CoVDxgK61D43Kutl9ltx8FffAnMEuYUhaGG1zAIrfX4n/rXfVNSilvGfkt7R4zLMyktQEXabs5JsPRVdbSmmuW3TwuHB0i+ixnFbcKdCT65xSSt710z9ZAn/dFxV724DQxQGTmjc27eOqTdw/pdESB16dX7D6nT3X+IdhQ5Y= Received: from HE1P189CA0029.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::42) by DB6P18901MB0103.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:25::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Thu, 28 Mar 2019 11:05:24 +0000 Received: from AM5EUR02FT005.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::202) by HE1P189CA0029.outlook.office365.com (2603:10a6:7:53::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1750.15 via Frontend Transport; Thu, 28 Mar 2019 11:05:24 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT005.mail.protection.outlook.com (10.152.8.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1730.9 via Frontend Transport; Thu, 28 Mar 2019 11:05:23 +0000 Received: from [31.133.151.123] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 28 Mar 2019 12:05:22 +0100 To: References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> From: Ludwig Seitz Message-ID: <22f70452-ae33-17a8-317e-1efbfc44d508@ri.se> Date: Thu, 28 Mar 2019 12:05:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090809050301010202040608" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(39850400004)(136003)(346002)(396003)(376002)(2980300002)(199004)(53754006)(189003)(51914003)(5024004)(7736002)(2906002)(305945005)(5660300002)(65806001)(229853002)(65826007)(14444005)(31686004)(568964002)(65956001)(5000100001)(6916009)(3846002)(6306002)(235185007)(6116002)(31696002)(6246003)(86362001)(97736004)(44832011)(36756003)(68736007)(53936002)(2351001)(386003)(966005)(74482002)(8676002)(53546011)(8936002)(69596002)(81166006)(16576012)(84326002)(6706004)(106466001)(22746008)(356004)(104016004)(11346002)(486006)(16526019)(77096007)(71190400001)(2616005)(476003)(478600001)(58126008)(16586007)(446003)(106002)(336012)(40036005)(126002)(64126003)(956004)(33964004)(76176011)(26005)(81156014)(186003)(316002)(22756006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P18901MB0103; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 224c02e5-f286-43c0-73e6-08d6b36d463c X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DB6P18901MB0103; X-MS-TrafficTypeDiagnostic: DB6P18901MB0103: X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0990C54589 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: v/7WWVIqRjdvnC/0vmayP55SgqVZCOOFlC8Kz/CmDj78u1R/SiKVXmTf/WU75eZEjdNhKL7hEfkfzGRSx21bVCgz2O3ccdp4BRYOOPyvn46oMpNUICoiM8w/WGmfCISAuloumSsgjYhUF3r6Du2UwbL7J62SpX/LOV5+elPKxVcemrozEOC8LbNE5PyE6lR0436HUI7bauE5CCQatTf/Mbq2QMDunPtOGMsDjbB1CbJLxdoDGtAAjdTrPrI7NXOzDqiP2LIK/tWANzlXX3cU+68Fkw8rCleqGROxXvuQE3xpaeWFqQyIKFMkhVl+AuaRL/TpQJDnEmRNDRuxhdEc+daH8R/2hRaqBukKQobKM/wXcnB+EIT+UkZvhVDA0lyeyD3nVwrKiHj8kHBGSR3vZtldj9ES3cMSSX0/9v7fKqY= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2019 11:05:23.0017 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 224c02e5-f286-43c0-73e6-08d6b36d463c X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0103 Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 11:05:40 -0000 --------------ms090809050301010202040608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 28/03/2019 11:17, Daniel Fett wrote: > Hi all, >=20 > I published the first version of the DPoP draft at=20 > https://tools.ietf.org/html/draft-fett-oauth-dpop-00 >=20 > Abstract >=20 > This document defines a sender-constraint mechanism for OAuth 2.0 > access tokens and refresh tokens utilizing an application-level > proof-of-possession mechanism based on public/private key pairs. >=20 >=20 > Thanks for the feedback I received so far from John, Mike, Torsten, and= =20 > others during today's session or before! >=20 > If you find any errors I would welcome if you open an issue in the=20 > GitHub repository at https://github.com/webhamster/draft-dpop >=20 > - Daniel >=20 > A quick nit: in figure 3 you seem to be using the "jwk" claim to include the pop-key=20 in the token. Any reason for not using the "cnf" claim from RFC 7800? /Ludwig --=20 Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 --------------ms090809050301010202040608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DT0wggYWMIID/qADAgECAg8BaKlzCTJTye3phLaz/cIwDQYJKoZIhvcNAQELBQAwRzELMAkG A1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBD bGFzcyAyIENBIHYyMB4XDTE5MDIwMTE0MjUxNVoXDTIxMDIwMTE0MjUxNFowgYsxCzAJBgNV BAYTAlNFMS4wLAYDVQQKDCVSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuIEFC MRUwEwYDVQQDDAxMdWR3aWcgU2VpdHoxEjAQBgNVBAUTCUx1ZHdpZ1NlaTEhMB8GCSqGSIb3 DQEJARYSbHVkd2lnLnNlaXR6QHJpLnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAlJNmRfcsto5I/yXrBIi9QroZtfAMttc1Eznv5iPCK++eFUArODhITO7k9rtlQX5D8vYF v4vzZex58YWZhvGMzDj9FdpD/PHKOxL/frlrreChuissPWo5M88DmL3V1oyGzvgeRqaafpEi 0/2+gezMFlABm/BXj3/0Fiw5Sxub7essE27EtDK05nAbUB69kfLHBEytbTAuuSb11hC1dpTf itMZkzSFwsBCyPtIv3GRt9xgnOPK4RRpHidv1GLYXNQQ7xEGhFy4qbZ2NSfM+56SSRswvW9P 5n81ZmZ4FWkiJouUIYtZ2ifncBJL4DC2chjsywDEz5No7kYrGxc5oOm1YQIDAQABo4IBuDCC AbQwHwYDVR0jBBgwFoAUnhn/5Q06/gCXFT9p8dxaPKoMlIMwHQYDVR0OBBYEFKZHZ8MZNNP5 tXMPjeFiw01pUWbtMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEB DDA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzAdBgNVHREEFjAUgRJsdWR3aWcuc2VpdHpAcmkuc2UwTQYDVR0fBEYwRDBCoECg PoY8aHR0cDovL2NybC0yLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNz MmNhdjIuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB+BggrBgEFBQcBAQRy MHAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnRydXN0LnRlbGlhLmNvbTBFBggrBgEFBQcw AoY5aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYWNsYXNzMmNh djIuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCk0GOalOCjEJObuBeMg0QREtBP/2ona16npn+T v5R3Vjk5UsQdOaOosgVjADX68C83dyfPiWR4UfNJoTBcM8JLpEXIm+xC4BiDPTPHYvgkhgXt 9VWCRWXOMfT/UPXjiGsbPuNWja1LQzF5KOmM826kHVZItHuDY6kJLE4OZ+apFvVKtSLQJJLA 4MlDVwp5+XsZi4cftcX5HdgLdChodUPKq3XVfALfXM/p81XEFBTYOHNplr3cQytDQjsnCZnS Ic4UpsxrArNxDO9+AKu/s1Fbq494AhHj4oHcg4DIjhHUzbPCLP19Gqp4dflr/V7Ulg3d+4Zh bmSAn1cffrzvvkjVrqMgQOoHQTl2QyO9n/oJ/9CSYRmhFsQMPun9LM/p5l58dTZp53B3LgA6 FFrxnntlZnTPh3bvsMJvUQ+AoiXyQwnkdxUrhoM+gUz36t3JSA8g48h7BhPsnwQ/YrarAhJ8 ifuzykTQmDseWLjJKyFflddy/azAlPQjgSMMWOZCo2s+l+WwPISf33nls2Aec/vvG5auYHS6 pwWuVKuwZTPgJfHanZTNpBM5y0jVBz6tr8AHZypnCONgyUYA4uec3v5oWz4FvLEnlKnMGoK3 OeFGvfHG0tbP25HbdN3AJYP0EUo56wfkBOYsnmn4mEYdk2GHkJNfaQRBJljH0T7TOcmcDjCC Bx8wggUHoAMCAQICEGN8C9eFpb8p2mAtfE16cLEwDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UE CgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQx MDE2MDgzOTMwWhcNMzIxMDE2MDUwNDAwWjBHMQswCQYDVQQGEwJTRTEUMBIGA1UECgwLVGVs aWFTb25lcmExIjAgBgNVBAMMGVRlbGlhU29uZXJhIENsYXNzIDIgQ0EgdjIwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC0PpW2qcWGnStqfa5DjrUi79Kz2SySUlJ1kiEQ1Pd/ LWbnsEwFYPqOJwAf6ZtEDtQ/9Z1VkVNQ6MkD++keqk7648x0YANgMyiJsWrbd0TKOObtlXdJ pb5qesJ5nOAdVeL3z6lgrkZx+fsUfTV+lLRGRh2+RWzZTjPAvKotY3nAwXCHtwI5v3FKuR10 aJ9+CEOka02KSUzGjcGZwMk2io0DxLELf1gPRvqE9xmn4ioXLqpluozb4Fo9ewydufTLQc3/ I63uPQh8BlLPPIGzWb4iBDq2zbWlbx0KlH/UlUZ7fjzp6N6cAqZ2NnDaCOnnIRfUYeNXFG8/ aiBeFOpEeEpclr5QUwr9HLKL1QiyQtc/wW8acQFoKuGi8myiAch7k7S0rmU5gT05je+OTzWh Oaw7gmDdndYY1mjkPkzpQ+hxyfnwUsAitUq9j0imFOLxKWLH4QNbyuDIMvDyezzJWzMy3XPB LiLSH9CBLVQHRoQ+WW8xD4rnmvQtoGZM72og2iNf4/JCHL1AJYhQtaRjYgm3rhvAP0HhSVAB Z5aHM52ylJHC3JwUyuFm8S9A2ffY9rUTffMLWmDCnX0QAP9bKr6+ACogm4DBUj3ftYodI2TD 6F8+VjSFuCzGDPuCjK+fQ2c3wqziwFl+NgoGI9Vgc6x5+0ocKkiQAIYFaQ3SyGmI6QIDAQAB o4ICFTCCAhEwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVz dC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAOBgNVHQ8BAf8EBAMC AQYwgcYGA1UdHwSBvjCBuzBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDB3oHWgc4ZxbGRhcDovL2NybC0xLnRydXN0 LnRlbGlhc29uZXJhLmNvbS9jbj1UZWxpYVNvbmVyYSUyMFJvb3QlMjBDQSUyMHYxLG89VGVs aWFTb25lcmE/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwHQYDVR0OBBYEFJ4Z /+UNOv4AlxU/afHcWjyqDJSDMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQB5wuZFNXR5ko9cu7PcpIyH8xaoGfpimP2GTg7qVuL92D/idIlj pqMm93WC9mgL/Uy6DExoF8xSLurLaiajoU+VG6ZWg0F7P1AXARNt0RpWI5SphxBQYM2751S8 vC/22k8Vi+qpQVIREqQPVXCIEH7U6eCY9gEVzdq9l1yPoI8n0D2a8V6GCv0RVkmIpa16rNYD tTw4j3Ha56/Ua33C3qeZh1dIfkaU2h4CGHd2Em3v5LLMsEh8dqUeG9yIcCU+8RUgDahNxWMe MGxzrhwk8WBV6xeoQp20p7cSHbSbyHJURC1n+nVrgdh8hbw6WOgFhNA5tCPDZ0oSF+uHfj+b ioZE3AlYdcEqHJA9A9sO58F4/Qg/yp9oYuT0ZpKb4hmzeqDXvk5KRFNfHlhTt35i+qmas9wB 11MXbYd5WwqEhZH6HWO5H7XKJP7olxmEC0W3OKlpKafq1iPsBN5ycRfUrXFss0Ax6vpCq0XA 3LYePpQ44hOU+qrkR1M0a7Eo3++3TpP4cV+FZiO4aZYZ3yZftSRHwWpGiDBdWOdTKR2GJi7Z z/OxacrmwmM1Z+WcigldbG8f3IMnOLK4X0uXjhVeAHrhuttQuM8i+4TNXgsZbmfEKNDQIQPO /lbacsGHWFB/U2y6SXVEkZs2xIciRA0iZNTv7mbIL8SZmf5wpbjDCYHiCjGCAzgwggM0AgEB MFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJhMSIwIAYDVQQDDBlUZWxp YVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIwDQYJYIZIAWUDBAIBBQCg ggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyODEx MDUyMFowLwYJKoZIhvcNAQkEMSIEIBBlnl5K6JHHXdKQcKvbPFoWVIU4hrKwhozmSvYsB3Np MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxFDASBgNVBAoMC1RlbGlhU29uZXJh MSIwIAYDVQQDDBlUZWxpYVNvbmVyYSBDbGFzcyAyIENBIHYyAg8BaKlzCTJTye3phLaz/cIw awYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMRQwEgYDVQQKDAtUZWxpYVNvbmVy YTEiMCAGA1UEAwwZVGVsaWFTb25lcmEgQ2xhc3MgMiBDQSB2MgIPAWipcwkyU8nt6YS2s/3C MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAKSwFy2I77fAucQhYR025e2eYklPOzKJBE1as9lsO2FYI Byb6C3VjYPk76wGCvlRAy9GOMSOAqlBGgQbeziwA+xOWMoOUzCWRhLlcBGucPN6fdNs5RB5f MISSzZDWGRbrJ3Yrkt995kNlhjVF1ki1LM2YwJb9ZYXO+lOr+j1/2XAwaNjvnmYspPrW135N zwhMsQhuwAfD9yGPGtsnIyI3AXsFlBby2NePz35j3ri5zvRkk3oRGlCRvewjwFzJJXxerPm0 hqS9uqLFXD8XjvGEhQ5tMoY0eZxg7TIsXVGnZ2ikLOeEaSY/GUN65slsiLWWD8pP0p//6Aco c399LMyy6QAAAAAAAA== --------------ms090809050301010202040608-- From nobody Thu Mar 28 04:31:13 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ED312052A for ; Thu, 28 Mar 2019 04:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 FUgbYOlclk18 for ; Thu, 28 Mar 2019 04:30:56 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650092.outbound.protection.outlook.com [40.107.65.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B341205B4 for ; Thu, 28 Mar 2019 04:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mMIjStP/0qE/IQ93eVyAt81TS2FDzPkXKQduw5cwGzg=; b=Hn3NhZvRcjVsnHLB/OEIeUviiqLU8sjuDaFYPkh8ibcseUL32jmqyi06h2ohnAq7Vb6QJxAmTZwCxmZAxLi4ouhkbi/ge/n17bWLjVPJBUqKMhQDPjZ7va9R7FFIKSJf/Hh84IQ8UpnZB5bjKKViYxEyXjowwFICq2VgN3osqAM= ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=kO/cqliXyw8fviWDj77aCleUk/UmwEjo84QZMUlIcxfnC5mNxsAm2eQQqvG586JhXh0JPG/eWt5Pp0upcHp3wuw97nyOAP9lTvUFgrde5E7v2Kx6+Wt4lhwxi9EakPQKKZobBi0PBQcOFOalw6QZ88VxLStfI3a0akTHOK6uq1c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mMIjStP/0qE/IQ93eVyAt81TS2FDzPkXKQduw5cwGzg=; b=gOK4lNH1g99nqpxXj1FjKqgy+2Q8/4GY8ETcaWl7rUjVtZs4qRZFTwO6yA8KMhlHq5sctubzbzpRE2iKi/90N7Ag07s7Vpj1hyfxvYJbcvj06lQSqUQ9gS25/MrWDDu6WehNDEYzNA7vHOn/DMahYbi3wiqQu3uMZjFomxlkOhc= ARC-Authentication-Results: i=1; test.office365.com 1;dmarc=none action=none header.from=microsoft.com;arc=none Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0340.namprd00.prod.outlook.com (52.132.20.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1790.0; Thu, 28 Mar 2019 11:28:52 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::601c:4d1:dc81:12dc]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::601c:4d1:dc81:12dc%7]) with mapi id 15.20.1791.000; Thu, 28 Mar 2019 11:28:52 +0000 From: Mike Jones To: Ludwig Seitz , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-fett-oauth-dpop-00 Thread-Index: AQHU5U+1X32rBXdg1kq2TBwNTiZWFKYg4aQAgAAGeMA= Date: Thu, 28 Mar 2019 11:28:51 +0000 Message-ID: References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <22f70452-ae33-17a8-317e-1efbfc44d508@ri.se> In-Reply-To: <22f70452-ae33-17a8-317e-1efbfc44d508@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=26537b83-631d-4ed0-a23f-0000efd82bbf; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-03-28T11:28:30+0100; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-originating-ip: [62.168.35.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eeaf14aa-24f3-41e2-42fc-08d6b3708e5e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BL0PR00MB0340; x-ms-traffictypediagnostic: BL0PR00MB0340: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(366004)(39860400002)(376002)(53754006)(13464003)(51914003)(189003)(199004)(6506007)(229853002)(53546011)(26005)(6346003)(102836004)(25786009)(186003)(6436002)(305945005)(76176011)(486006)(10290500003)(446003)(476003)(6246003)(11346002)(86612001)(81166006)(7696005)(86362001)(71200400001)(71190400001)(110136005)(8676002)(81156014)(966005)(52536014)(14454004)(256004)(14444005)(72206003)(478600001)(5660300002)(8936002)(99286004)(22452003)(6306002)(55016002)(97736004)(53936002)(9686003)(2906002)(10090500001)(68736007)(316002)(74316002)(6116002)(3846002)(7736002)(33656002)(66066001)(8990500004)(2501003)(105586002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0340; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Ny1HckkSunYEGSsUAZP0Ape1VJocgmexahbOWXYNfizC6ZjaLRLds2G8HlFwdaawE9MzbOUpiNnuCCBPa2Ad59LewuS8VxXbmPCGKsKe8TpRuKjM519baZx4X9T5p3JubxbqLnGJBl6LpHEqi58uZPF2MfsyUfTI4o7qkknDipl1LeQvEiPQ94jjx5cFjzV5K7QcKp8OOGVR0nnBb5RmGdecCNx69a3pn1oefJlKB+1T7iWHB7AEtANQ/3exs2MlXx+PW0/FftdVO4FhdQ1GQ4JffDDvHCTt8Mm0C548aQj+skvjKelaosJ4ogruu3CfecQVnFPTHeumc/QBohJBF0vsStGUUDWuVb0YfEvpDbkC+sxq9Rjhq6qzaF36AFywtPgQFIdC8ukGwnN93I9G+obBaHyw5EDxqqgMx79HU08= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: eeaf14aa-24f3-41e2-42fc-08d6b3708e5e X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 11:28:51.8779 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0340 Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 11:31:12 -0000 R29vZCBvYnNlcnZhdGlvbiwgTHVkd2lnLiAgV2Ugc2hvdWxkIGRvIHRoYXQuDQoNCgkJCQktLSBN aWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEx1ZHdpZyBTZWl0eg0KU2VudDogVGh1cnNkYXks IE1hcmNoIDI4LCAyMDE5IDEyOjA1IFBNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIGRyYWZ0LWZldHQtb2F1dGgtZHBvcC0wMA0KDQpPbiAyOC8wMy8yMDE5IDEx OjE3LCBEYW5pZWwgRmV0dCB3cm90ZToNCj4gSGkgYWxsLA0KPiANCj4gSSBwdWJsaXNoZWQgdGhl IGZpcnN0IHZlcnNpb24gb2YgdGhlIERQb1AgZHJhZnQgYXQNCj4gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWZldHQtb2F1dGgtZHBvcC0wMA0KPiANCj4gQWJzdHJhY3QNCj4gDQo+ ICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBzZW5kZXItY29uc3RyYWludCBtZWNoYW5pc20g Zm9yIE9BdXRoIDIuMA0KPiAgICAgYWNjZXNzIHRva2VucyBhbmQgcmVmcmVzaCB0b2tlbnMgdXRp bGl6aW5nIGFuIGFwcGxpY2F0aW9uLWxldmVsDQo+ICAgICBwcm9vZi1vZi1wb3NzZXNzaW9uIG1l Y2hhbmlzbSBiYXNlZCBvbiBwdWJsaWMvcHJpdmF0ZSBrZXkgcGFpcnMuDQo+IA0KPiANCj4gVGhh bmtzIGZvciB0aGUgZmVlZGJhY2sgSSByZWNlaXZlZCBzbyBmYXIgZnJvbSBKb2huLCBNaWtlLCBU b3JzdGVuLCANCj4gYW5kIG90aGVycyBkdXJpbmcgdG9kYXkncyBzZXNzaW9uIG9yIGJlZm9yZSEN Cj4gDQo+IElmIHlvdSBmaW5kIGFueSBlcnJvcnMgSSB3b3VsZCB3ZWxjb21lIGlmIHlvdSBvcGVu IGFuIGlzc3VlIGluIHRoZSANCj4gR2l0SHViIHJlcG9zaXRvcnkgYXQgaHR0cHM6Ly9naXRodWIu Y29tL3dlYmhhbXN0ZXIvZHJhZnQtZHBvcA0KPiANCj4gLSBEYW5pZWwNCj4gDQo+DQoNCkEgcXVp Y2sgbml0Og0KDQppbiBmaWd1cmUgMyB5b3Ugc2VlbSB0byBiZSB1c2luZyB0aGUgImp3ayIgY2xh aW0gdG8gaW5jbHVkZSB0aGUgcG9wLWtleSBpbiB0aGUgdG9rZW4uIEFueSByZWFzb24gZm9yIG5v dCB1c2luZyB0aGUgImNuZiIgY2xhaW0gZnJvbSBSRkMgNzgwMD8NCg0KL0x1ZHdpZw0KDQoNCi0t DQpMdWR3aWcgU2VpdHosIFBoRA0KU2VjdXJpdHkgTGFiLCBSSVNFDQpQaG9uZSArNDYoMCk3MC0z NDkgOTIgNTENCg0K From nobody Thu Mar 28 11:49:02 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BBF120302 for ; Thu, 28 Mar 2019 11:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VWlw98C72rLZ for ; Thu, 28 Mar 2019 11:48:58 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C3C12000F for ; Thu, 28 Mar 2019 11:48:57 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id t8so14058306otp.7 for ; Thu, 28 Mar 2019 11:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Jb16LJjEaJ5dc47Q3njbDpdDWpnA1IDrMe4GgqHyO4=; b=DtrcfO3uC6vWIg9n8fSKjgrbWpm1IrwZOZb1oK1agUYLH573bcBptijy1ZDiR++OFn amf0ypeOdBmqNuhNvd6nFt2nJwpsylBINedFLLvUqbeQdRPa7/tU10xPdCdA8IV+cYki qRjg4bUK0U3+Xt/OWshdkYk4eCShd34xyS58i0twabYPfKZ+l6Zbnc4d/xJDymEzu2h/ KVqXBm4oYZCxaHpZ0aKvQssZJlWpYoMd54E6czJQZathaV0MyGg6/H6jLiPtN+auETTX B8FkPHCCbrDWCNZlFcs5O1zmxHTq4jySzwfvOwpw1UnHe2Apzn/jxgWb5WsWkOhgUDm/ lT0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Jb16LJjEaJ5dc47Q3njbDpdDWpnA1IDrMe4GgqHyO4=; b=YwSuGW5DuHiJ/p+K/BDZdrZ3/ajdlVxrwNDVKeMm7GA7xrAybae8jahQDGghTAM0Wn 3gR7GUcQp4AMf7F0qVbs8yHjNmaa3HheNHGnkMkk+IjmbuI3xEQErPZqAR1FYEoHHY9b oUsCmLpmA4xRB/b7JkBb5l+aWV/jJEicSEwFdRJei3MJliMLR4wAqJr2fEx4h0TYXuP1 wVgByqBr/bu/vXDrGCzgwK8lQx8H37ti+OMOm8bSnORPMmbAZNtvXvZqCyCvp/kY47e1 xQwZZhQfhFVF/1lHK6LqUNM1znUFh2j5cqDlAsH7TQHwiwk84lHp/eP/mSvZjqL2T+gK 0f8g== X-Gm-Message-State: APjAAAWf4aPeB8m/b24MHGK0aKyeSYCPdjeKTvB3LqQs484cY+yWUREc wAU0JeXpvayYGMcU6e/iP/oXeMV3I5L1uedCgg== X-Google-Smtp-Source: APXvYqyJ+292g9dI75ApUpuQvPL7I93K1g1knGOenGYdZRd2nRLmdocdL9Tk205zVbh9hH6Sg+YQMJGtfPpCbg5B8l4= X-Received: by 2002:a9d:71c3:: with SMTP id z3mr31559124otj.177.1553798936942; Thu, 28 Mar 2019 11:48:56 -0700 (PDT) MIME-Version: 1.0 References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> In-Reply-To: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> From: Filip Skokan Date: Thu, 28 Mar 2019 19:48:45 +0100 Message-ID: To: Daniel Fett Cc: oauth Content-Type: multipart/alternative; boundary="000000000000b05b5705852c0199" Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 18:49:01 -0000 --000000000000b05b5705852c0199 Content-Type: text/plain; charset="UTF-8" Hello Daniel, everyone, I've hacked together an AS implementation to enable client-side experimentation using this draft. You can find this hosted at https://draft-fett-oauth-dpop-00.herokuapp.com (it's also the issuer identifier). There's a default client registered and dynamic registration is also open, so hack away. It's using the draft version with dpop_binding expecting "jwk": { ...jwk } rather then "cnf": { "dpop+jwk": { ... jwk } } as the payload claim as suggested by Ludwig. There are more notes on the index page itself. Aaron kindly accepted to work on the SPA client-side demonstration, I'm not a SPA guru mastermind like Aaron and it would take me ages to deliver that particular piece. That being said I did test this with a regular web app as well as a CLI client using both code+pkce and dynamic port binding as well as device authorization grant client. Works. Feeding back to the draft - i think we should mention the client to provide reasonable expiration value of the dpop JWTs (max minutes). Altho not critical since we require a jti, as an AS i don't wanna cache the used jti values forever :) - the AS should error when the dpop JWT contains private key material - altho implied by the use of "public" and "private" key i think it wouldn't hurt explicitly forbidding "oct" JWKs - i don't see a point in dpop_proof containing the JWK again unless the AS is supposed to do something new with it - it wouldn't hurt mentioning that, kinda following 6750, when dpop_proof is sent it's in a query for GET, in the request body for a POST. my provider for instance will ignore query parameters during a POST. With that said, what about RS endpoints using other methods? Maybe placing the proof in a header isn't a terrible idea afterall. Kind Regards, *Filip Skokan* On Thu, 28 Mar 2019 at 11:19, Daniel Fett wrote: > Hi all, > > I published the first version of the DPoP draft at > https://tools.ietf.org/html/draft-fett-oauth-dpop-00 > > Abstract > > This document defines a sender-constraint mechanism for OAuth 2.0 > access tokens and refresh tokens utilizing an application-level > proof-of-possession mechanism based on public/private key pairs. > > > Thanks for the feedback I received so far from John, Mike, Torsten, and > others during today's session or before! > > If you find any errors I would welcome if you open an issue in the GitHub > repository at https://github.com/webhamster/draft-dpop > > - Daniel > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b05b5705852c0199 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello Daniel, everyone,
    I've hacked together an AS implementation to enable client= -side experimentation using this draft.

    You can fi= nd this hosted at=C2=A0https://draft-fett-oauth-dpop-00.herokuapp.com=C2=A0(it's a= lso the issuer identifier). There's a default client registered and dyn= amic registration is also open, so hack away. It's using the draft vers= ion with dpop_binding expecting "jwk": { ...jwk } rather then &qu= ot;cnf": { "dpop+jwk": { ... jwk } } as the payload claim as= suggested by Ludwig.

    There are more notes on the = index page itself.

    Aaron kindly accepted to work o= n the SPA client-side demonstration, I'm not a SPA guru mastermind like= Aaron and it would take me ages to deliver that particular piece. That bei= ng said I did test this with a regular web app as well as a CLI client usin= g both code+pkce and dynamic port binding as well as device authorization g= rant client. Works.

    Feeding back to the draft
    • i think we should mention the client to provide reasonable ex= piration value of the dpop JWTs (max minutes). Altho not critical since we = require a jti, as an AS i don't wanna cache the used jti values forever= :)
    • the AS should error when the dpop JWT contains private key mate= rial
    • altho implied by the use of "public" and "priva= te" key i think it wouldn't hurt explicitly forbidding "oct&q= uot; JWKs
    • i don't see a point in dpop_proof containing the JWK = again unless the AS is supposed to do something new with it
    • it woul= dn't hurt mentioning that, kinda following 6750, when dpop_proof is sen= t it's in a query for GET, in the request body for a POST. my provider = for instance will ignore query parameters during a POST. With that said, wh= at about RS endpoints using other methods? Maybe placing the proof in a hea= der isn't a terrible idea afterall.

    Kind Regards,
    Filip Skokan


    On Thu, 28 Mar 2019 at 11:19, Daniel Fett <danielf+oauth@yes.com> wrote:
    =20 =20 =20

    Hi all,

    I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop= -00

    Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.

    Thanks for the feedback I received so far from John, Mike, Torsten, and others during today's session or before!

    If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-= dpop

    - Daniel =C2=A0=C2=A0

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --000000000000b05b5705852c0199-- From nobody Fri Mar 29 09:39:17 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EC61200CC for ; Fri, 29 Mar 2019 09:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ryevp1f-mjry for ; Fri, 29 Mar 2019 09:39:13 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0ED12004C for ; Fri, 29 Mar 2019 09:39:13 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id w139so2140481oie.9 for ; Fri, 29 Mar 2019 09:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bm9Ubhm9o+wh9A62V6dK1lvyBG0Tpgy812mr9ivboaM=; b=F1dT+KdmjWzWnHOm68oULS/Ll7pdz5gmqNjzHwV2JWfbIGM3WhAI+SChPNt0DOfN3r ODJdU1iaH9BBJvUIGHuJowPgDOVY9ihEFGQBdA3laViAR9tDhXZvVGlgvWxYsu+8WoXm Jz9uHadg/ESj+GYQ299ZPtjE6IdKBGFAHpEt9+zpXtn8O8Rdfp0r2OeTiOqQ2YRIf164 nqDfTj4FYhHOpUBut04j9cNARgWSl1ZwtQ7J2xDP+yV7aepv6GQxkCimTWazY49a2qpP FnltorqoRXPqz4C1FNphSFYSa8hAACNQOPqBFDjqlnh0rF9Usho8R/5KwBGk0l9PO5EO 0IrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bm9Ubhm9o+wh9A62V6dK1lvyBG0Tpgy812mr9ivboaM=; b=rzjh7AuFvlz2N17wtaMYAxBHVnPFIGVdcTpW3SjRYtGO9M6rLO02QTOK9JHPNFSn5c SITUDehZBfM2l8J2Jzoz38LCRbLBmZxwUHIfGPVYuBHyZVVaDsnMMQUErDlba5x4MyCT Kc9oeVbNWVbN6nlu9GWugXhVwT5ZRVJ5wLxMwQsUONYyjAS91ETViRB6VjiS9rS+WgTT 1RHSqMyOEWHgFdv14sJ46SnK7rDHKcYvMr1xus82hV8OZXqe11L0gxHbZ6KLiALEeS/e 06VCHfhyHS/NlM7mwEVnsTO9oPcb6zRurfeKfLzss4cWvLQAkvgEvrkYKItxJLHVh0Wa +oWQ== X-Gm-Message-State: APjAAAXSJAOmIIFFLzVbyWZFMky6zlPw2yoLTQxMkyVM3vYK71KMzrsZ d9Klh+LNWa6ESRTTf4NyaPVGd24xxPXOg1HdwQ== X-Google-Smtp-Source: APXvYqzb0irP3yqkI3HjyUhey7eslmqekGIX5fXTOXSG/87ltTAUZliaHsfzrvV5wUb0MU9HE5vAiQs10XEy04N/PUc= X-Received: by 2002:aca:aa91:: with SMTP id t139mr4389880oie.174.1553877552690; Fri, 29 Mar 2019 09:39:12 -0700 (PDT) MIME-Version: 1.0 References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> In-Reply-To: From: Filip Skokan Date: Fri, 29 Mar 2019 17:39:01 +0100 Message-ID: To: Daniel Fett Cc: oauth Content-Type: multipart/alternative; boundary="0000000000008d7f6c05853e4ffb" Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 16:39:16 -0000 --0000000000008d7f6c05853e4ffb Content-Type: text/plain; charset="UTF-8" And here's a real simple client-side implementation using - Webcrypto API - IndexedDB API - fetch https://boiling-escarpment-16732.herokuapp.com/ It's not really a SPA but uses the same browser APIs and no backend other than a web server hosting the html. Best, *Filip Skokan* On Thu, 28 Mar 2019 at 19:48, Filip Skokan wrote: > Hello Daniel, everyone, > > I've hacked together an AS implementation to enable client-side > experimentation using this draft. > > You can find this hosted at https://draft-fett-oauth-dpop-00.herokuapp.com (it's > also the issuer identifier). There's a default client registered and > dynamic registration is also open, so hack away. It's using the draft > version with dpop_binding expecting "jwk": { ...jwk } rather then "cnf": { > "dpop+jwk": { ... jwk } } as the payload claim as suggested by Ludwig. > > There are more notes on the index page itself. > > Aaron kindly accepted to work on the SPA client-side demonstration, I'm > not a SPA guru mastermind like Aaron and it would take me ages to deliver > that particular piece. That being said I did test this with a regular web > app as well as a CLI client using both code+pkce and dynamic port binding > as well as device authorization grant client. Works. > > Feeding back to the draft > > - i think we should mention the client to provide reasonable > expiration value of the dpop JWTs (max minutes). Altho not critical since > we require a jti, as an AS i don't wanna cache the used jti values forever > :) > - the AS should error when the dpop JWT contains private key material > - altho implied by the use of "public" and "private" key i think it > wouldn't hurt explicitly forbidding "oct" JWKs > - i don't see a point in dpop_proof containing the JWK again unless > the AS is supposed to do something new with it > - it wouldn't hurt mentioning that, kinda following 6750, when > dpop_proof is sent it's in a query for GET, in the request body for a POST. > my provider for instance will ignore query parameters during a POST. With > that said, what about RS endpoints using other methods? Maybe placing the > proof in a header isn't a terrible idea afterall. > > > Kind Regards, > *Filip Skokan* > > > On Thu, 28 Mar 2019 at 11:19, Daniel Fett wrote: > >> Hi all, >> >> I published the first version of the DPoP draft at >> https://tools.ietf.org/html/draft-fett-oauth-dpop-00 >> >> Abstract >> >> This document defines a sender-constraint mechanism for OAuth 2.0 >> access tokens and refresh tokens utilizing an application-level >> proof-of-possession mechanism based on public/private key pairs. >> >> >> Thanks for the feedback I received so far from John, Mike, Torsten, and >> others during today's session or before! >> >> If you find any errors I would welcome if you open an issue in the GitHub >> repository at https://github.com/webhamster/draft-dpop >> >> - Daniel >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --0000000000008d7f6c05853e4ffb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    And here's a real simple client-= side implementation using

    - Webcrypto API
    -=C2=A0IndexedDB API
    - fetch


    It's not rea= lly a SPA but uses the same browser APIs and no backend other than a web se= rver hosting the html.

    Best,
    Filip Skokan


    On T= hu, 28 Mar 2019 at 19:48, Filip Skokan <panva.ip@gmail.com> wrote:
    Hello Daniel= , everyone,

    I've hacked together an AS impleme= ntation to enable client-side experimentation using this draft.
    <= br>
    You can find this hosted at=C2=A0https://draft-fett-oauth-= dpop-00.herokuapp.com=C2=A0(it's also the issuer identifier). There= 's a default client registered and dynamic registration is also open, s= o hack away. It's using the draft version with dpop_binding expecting &= quot;jwk": { ...jwk } rather then "cnf": { "dpop+jwk&qu= ot;: { ... jwk } } as the payload claim as suggested by Ludwig.
    <= br>
    There are more notes on the index page itself.

    =
    Aaron kindly accepted to work on the SPA client-side demonstrati= on, I'm not a SPA guru mastermind like Aaron and it would take me ages = to deliver that particular piece. That being said I did test this with a re= gular web app as well as a CLI client using both code+pkce and dynamic port= binding as well as device authorization grant client. Works.
    Feeding back to the draft
    • i think we should m= ention the client to provide reasonable expiration value of the dpop JWTs (= max minutes). Altho not critical since we require a jti, as an AS i don'= ;t wanna cache the used jti values forever :)
    • the AS should error w= hen the dpop JWT contains private key material
    • altho implied by the= use of "public" and "private" key i think it wouldn= 9;t hurt explicitly forbidding "oct" JWKs
    • i don't see= a point in dpop_proof containing the JWK again unless the AS is supposed t= o do something new with it
    • it wouldn't hurt mentioning that, ki= nda following 6750, when dpop_proof is sent it's in a query for GET, in= the request body for a POST. my provider for instance will ignore query pa= rameters during a POST. With that said, what about RS endpoints using other= methods? Maybe placing the proof in a header isn't a terrible idea aft= erall.

    Kind Regards= ,
    Filip Skokan


    On Thu, 28 Mar 2019 at 11:19, Danie= l Fett <dan= ielf+oauth@yes.com> wrote:
    =20 =20 =20

    Hi all,

    I published the first version of the DPoP draft at https://tools.ietf.or= g/html/draft-fett-oauth-dpop-00

    Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.

    Thanks for the feedback I received so far from John, Mike, Torsten, and others during today's session or before!

    If you find any errors I would welcome if you open an issue in the GitHub repository at https://= github.com/webhamster/draft-dpop

    - Daniel =C2=A0=C2=A0

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --0000000000008d7f6c05853e4ffb-- From nobody Sat Mar 30 02:15:37 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57253120188 for ; Sat, 30 Mar 2019 02:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 axC3OX3Fq4R7 for ; Sat, 30 Mar 2019 02:15:35 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5628A120196 for ; Sat, 30 Mar 2019 02:15:33 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2U9FR5E023754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Mar 2019 05:15:29 -0400 Date: Sat, 30 Mar 2019 04:15:27 -0500 From: Benjamin Kaduk To: Vittorio Bertocci Cc: Steinar Noem , IETF oauth WG Message-ID: <20190330091527.GO35679@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 09:15:36 -0000 Hi Vittorio, On Tue, Mar 26, 2019 at 09:48:08AM -0700, Vittorio Bertocci wrote: > thank you Steinar and everyone else for the comments on this! > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, > Bertrand recommend using sub only for users. Martin would like to have the > sub for app only flows as well. Hans is neutral. > That does sound like the sub as user has more consensus, tho before > changing it I'd wait for the people currently at IETF104 to have more time > to comment as well. I'm not the responsible AD for OAuth, but as irresponsible AD let me point out that the WG chairs need to look at the "why" and not just the headcount of support, when they determine what has consensus (or lack of consensus). But I think we have seen some good arguments presented in this thread, so hopefully the chairs' job will not be very difficult. -Ben From nobody Sat Mar 30 10:35:10 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD3D12020A for ; Sat, 30 Mar 2019 10:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com 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 eRoBxK1zgH1x for ; Sat, 30 Mar 2019 10:35:06 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E891201DC for ; Sat, 30 Mar 2019 10:35:05 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id g7so3502711lfh.10 for ; Sat, 30 Mar 2019 10:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AgcgyG8GVw4RX+fmcD6CSGmh0B5Tro42Tv5poOUg4A8=; b=kDP+C+FSCB9EmJgC0o8BquHYAZK/ybJ+hKnbmS+BWhgcWkyq8E9IQFzqvmEsrEZnB8 iHaEjOE2pVwoCLnYQ54G5BUEiI5ksOa8AXL+2XyOt8TuuoF1jyOuS58myWadIv4Zbk+s 7VjA6Vd+/Y5Gtf+xbHytLpFvxRjF0X3k9dlAYjApPwKygCwWKS1q+3xvnTk78WUvG5Oy yMAdOsMqaYit+SS6xxBSIWnbL1PgTCBKjzZAOE9IHhnfxvCH8s6Wg1eqrImZrMis4X0e kjcmQHluMCKj36tJF4lqHZUlnci42awo5oya0fYEJb2BlxoXvWexcu1uBzYk3azb3ArE pI6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AgcgyG8GVw4RX+fmcD6CSGmh0B5Tro42Tv5poOUg4A8=; b=ASZhDXu4wOqBDB7ysy+o/ojZTKSLnyzCs8Qt/2WPPkeXExrei53wO1Bhi49+S3Td1s W1LA05gPPaHRGh9lPc13HhvBKS/30D7ZV0geh4n10I22TyMNx2elueMSCKdbgReR1lNt n3ypfhkZgAQMgIsMEBy7qXvcaT5qJwKUv0oGE5xDcNelvysEPV1K8tcKeiTQDlP8+RIB mVm+PLlB0P22CiaYt5/sSX+/lorbU13WSW/YVwVoneXhCm6qhkPx8Q+KTqeY1O1T2CJv E/X8YSawhNRJ5AUNSDIPG0l8nT7cJtf/GzR70aMDoJYqS524/7ozBPa4b3YGaKNOQ0Um iO3A== X-Gm-Message-State: APjAAAUn5wupe+dZGe7EM9sqFBtrnOc5XEsM0JL80fBQQ8oooYZIY/IW EAxIeAGPidm2uRCfPnB8TNvb015LLG8czsaCix9FPg== X-Google-Smtp-Source: APXvYqxjzzVQ5dNkUgbjbAnuzfsfM8UFB846K8C3etsK3n3GnOBF9O7OYmhUYP22iC5ClZLAHhNFIdg7sPEsm5G/7o8= X-Received: by 2002:a19:9e0d:: with SMTP id h13mr27768921lfe.51.1553967303634; Sat, 30 Mar 2019 10:35:03 -0700 (PDT) MIME-Version: 1.0 References: <20190330091527.GO35679@kduck.mit.edu> In-Reply-To: <20190330091527.GO35679@kduck.mit.edu> From: Vittorio Bertocci Date: Sat, 30 Mar 2019 10:34:52 -0700 Message-ID: To: Benjamin Kaduk Cc: IETF oauth WG , Steinar Noem Content-Type: multipart/alternative; boundary="000000000000204b05058553350d" Archived-At: Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 17:35:08 -0000 --000000000000204b05058553350d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Benjamin, Of course I agree that sheer headcount isn=E2=80=99t the main factor :). The main point here is that this is a profile meant to promote and facilitate interoperability, so _as long as a proposal is is sound & secure_, the number of products and services favoring it does have direct impact on adoption & expectations of successful interop. I agree that the =E2=80=9Cwhy=E2=80=9D remains the highest order bit, and as you mentioned w= e have seen good arguments. On Sat, Mar 30, 2019 at 02:15 Benjamin Kaduk wrote: > Hi Vittorio, > > On Tue, Mar 26, 2019 at 09:48:08AM -0700, Vittorio Bertocci wrote: > > thank you Steinar and everyone else for the comments on this! > > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, > > Bertrand recommend using sub only for users. Martin would like to have > the > > sub for app only flows as well. Hans is neutral. > > That does sound like the sub as user has more consensus, tho before > > changing it I'd wait for the people currently at IETF104 to have more > time > > to comment as well. > > I'm not the responsible AD for OAuth, but as irresponsible AD let me poin= t > out that the WG chairs need to look at the "why" and not just the headcou= nt > of support, when they determine what has consensus (or lack of consensus)= . > But I think we have seen some good arguments presented in this thread, so > hopefully the chairs' job will not be very difficult. > > -Ben > --000000000000204b05058553350d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hey Benjamin,
    Of course= I agree that sheer headcount isn=E2=80=99t the main factor :).=C2=A0
    =
    The main point here is that this is a profile meant to pr= omote and facilitate interoperability, so _as long as a proposal is is soun= d & secure_, the number of products and services favoring it does have = direct impact on adoption & expectations of successful interop. I agree= that the =E2=80=9Cwhy=E2=80=9D remains the highest order bit, and as you m= entioned we have seen good arguments.

    On Sat, Mar 30, 2019 at 02:15 Ben= jamin Kaduk <kaduk@mit.edu> wrot= e:
    Hi Vittorio,

    On Tue, Mar 26, 2019 at 09:48:08AM -0700, Vittorio Bertocci wrote:
    > thank you Steinar and everyone else for the comments on this!
    > To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,=
    > Bertrand recommend using sub only for users. Martin would like to have= the
    > sub for app only flows as well. Hans is neutral.
    > That does sound like the sub as user has more consensus, tho before > changing it I'd wait for the people currently at IETF104 to have m= ore time
    > to comment as well.

    I'm not the responsible AD for OAuth, but as irresponsible AD let me po= int
    out that the WG chairs need to look at the "why" and not just the= headcount
    of support, when they determine what has consensus (or lack of consensus).<= br> But I think we have seen some good arguments presented in this thread, so hopefully the chairs' job will not be very difficult.

    -Ben
    --000000000000204b05058553350d-- From nobody Sat Mar 30 13:51:27 2019 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C32E912028C; Sat, 30 Mar 2019 13:51:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter via Datatracker To: Cc: draft-ietf-oauth-jwt-bcp.all@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Brian Carpenter Message-ID: <155397908561.3942.9798054943934320825@ietfa.amsl.com> Date: Sat, 30 Mar 2019 13:51:25 -0700 Archived-At: Subject: [OAUTH-WG] Genart last call review of draft-ietf-oauth-jwt-bcp-04 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 20:51:26 -0000 Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-oauth-jwt-bcp-04 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-oauth-jwt-bcp-04.txt Reviewer: Brian Carpenter Review Date: 2019-03-31 IETF LC End Date: 2019-04-08 IESG Telechat date: Summary: Ready with (minor) issues -------- Minor issues: ------------- > 2.3. Multiplicity of JSON encodings > > Previous versions of the JSON format [RFC8259] allowed several > different character encodings: UTF-8, UTF-16 and UTF-32. This is not > the case anymore, with the latest standard only allowing UTF-8. > However older implementations may result in the JWT being > misinterpreted by its recipient. Why is that a security issue? > 3.6. Avoid Length-Dependent Encryption Inputs ... > ...It is > RECOMMENDED to avoid any compression of data before encryption since > such compression often reveals information about the plaintext. I'd like a citation for that, because it isn't intuitive. (And compression after encryption is pointless, of course.) > 3.10. Do Not Trust Received Claims Both the recommendations in this section seem imprecise. Maybe there should be some hints about the verification processes. From nobody Sat Mar 30 16:39:15 2019 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7946120340 for ; Sat, 30 Mar 2019 16:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.04 X-Spam-Level: X-Spam-Status: No, score=-4.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 462gd4T2vxq8 for ; Sat, 30 Mar 2019 16:39:11 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 8C54A12033D for ; Sat, 30 Mar 2019 16:39:11 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2UNYZhC172324 for ; Sat, 30 Mar 2019 23:39:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : subject : to : message-id : date : mime-version : content-type; s=corp-2018-07-02; bh=39U1MNQpR+9ZfUkB1tU7J1qMp+1VpM4jly+DS9SH1ZY=; b=cXsGYh37W8Z+4Rki6r+8e5YcQJvILUIh18ptLhH66GvL//dtqpJuouPCcI1frgEjR6sA 6zYjW9iG8BZuDfOZkPte31y5gAJ7gW000nDy3hpsmrJtfkMl1Vn+Vf+2YylzBnqllxyq 7lJimHtXqHADPAGVFkLlHmyTDjW4aPJClbP/heJ1Qymcws7e1YmNZAVmeVnWojChdsum xnXJZOjNZS4uV7VP8Zfpvxnqb8FNCvrJhh2nh63/vgxa+PD82xUJvZlbhAA7GJfnMyls ZWm/D8ur+HqUDN9HEy2eBTanOYca/j1gXwhCdtiBnLBNhDteIChq26jxN1Ry2rTeNOJr dg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2rj13psqbq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 30 Mar 2019 23:39:08 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x2UNd7oA029008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 30 Mar 2019 23:39:07 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2UNd6Px024098 for ; Sat, 30 Mar 2019 23:39:07 GMT Received: from [10.39.212.164] (/10.39.212.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 30 Mar 2019 16:39:06 -0700 From: rich levinson Organization: Oracle Corporation To: oauth@ietf.org Message-ID: <2979ec5a-195c-21db-48a6-46a627833a9f@oracle.com> Date: Sat, 30 Mar 2019 19:39:05 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------46E49D4BA1A3851FC79DC78D" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9212 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903300173 Archived-At: Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 23:39:15 -0000 This is a multi-part message in MIME format. --------------46E49D4BA1A3851FC79DC78D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Speaking for myself, as a long time user of OAuth 2.0, I am very enthusiastic about the new proposal:   "OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer"   https://tools.ietf.org/html/draft-fett-oauth-dpop-00 I believe it represents a real milestone for OAuth in that it appears to me to be the first proposal that is capable of offering true end-to-end integrity by using the OAuth 2.0 protocol at the application layer. In addition to the basic proof of possession capability, it inherently contains the mechanism for the client to completely protect any request that can be decomposed into a set of key:value pairs, which can then be signed within a JWT. The additional key:value pairs can be included in a Resource Access POST request, as described in section 5, by placing them in a 2nd JWT using the same public key and format as Figure 3, in a parameter with a name required by the Resource Server Application, for example, "dpop_appl_request". Since the parameter will be in the body of a POST request, there should be no size limitation for the set of key:value pairs that can be provided. Furthermore, the Access Token received in response to the token request shown in Figure 3, should cover the "dpop_appl_request" parameter, in the same way it covers the "dpop_proof" parameter described in section 5, because it covers the usage of the public key, and any specific content that is protected by that public key. The Access Token implicitly contains the user consent, the authorization of the IdP, plus the public key of the client making the request, and therefore the "dpop_appl_request" can potentially be usable to preserve the signature and possibly be used in some cases for non-repudiation, a capability that is not possible using the transport layer protocols, which remove all the protocol protection before delivering the request to the Resource Server Appl. In summary, the dpop at the appl layer proposal, imo, represents a significant advance in OAuth 2.0 technology that potentially addresses many of the security requirements that OAuth 2.0 does not currently provide.   Thanks,   Rich Levinson Re: [OAUTH-WG] draft-fett-oauth-dpop-00 Filip Skokan Fri, 29 March 2019 16:39 UTCShow header And here's a real simple client-side implementation using - Webcrypto API - IndexedDB API - fetch https://boiling-escarpment-16732.herokuapp.com/ It's not really a SPA but uses the same browser APIs and no backend other than a web server hosting the html. Best, *Filip Skokan* On Thu, 28 Mar 2019 at 19:48, Filip Skokan ; wrote: > Hello Daniel, everyone, > > I've hacked together an AS implementation to enable client-side > experimentation using this draft. > > You can find this hosted at https://draft-fett-oauth-dpop-00.herokuapp.com (it's > also the issuer identifier). There's a default client registered and > dynamic registration is also open, so hack away. It's using the draft > version with dpop_binding expecting "jwk": { ...jwk } rather then "cnf": { > "dpop+jwk": { ... jwk } } as the payload claim as suggested by Ludwig. > > There are more notes on the index page itself. > > Aaron kindly accepted to work on the SPA client-side demonstration, I'm > not a SPA guru mastermind like Aaron and it would take me ages to deliver > that particular piece. That being said I did test this with a regular web > app as well as a CLI client using both code+pkce and dynamic port binding > as well as device authorization grant client. Works. > > Feeding back to the draft > > - i think we should mention the client to provide reasonable > expiration value of the dpop JWTs (max minutes). Altho not critical since > we require a jti, as an AS i don't wanna cache the used jti values forever > :) > - the AS should error when the dpop JWT contains private key material > - altho implied by the use of "public" and "private" key i think it > wouldn't hurt explicitly forbidding "oct" JWKs > - i don't see a point in dpop_proof containing the JWK again unless > the AS is supposed to do something new with it > - it wouldn't hurt mentioning that, kinda following 6750, when > dpop_proof is sent it's in a query for GET, in the request body for a POST. > my provider for instance will ignore query parameters during a POST. With > that said, what about RS endpoints using other methods? Maybe placing the > proof in a header isn't a terrible idea afterall. > > > Kind Regards, > *Filip Skokan* > > > On Thu, 28 Mar 2019 at 11:19, Daniel Fett ; wrote: > >> Hi all, >> >> I published the first version of the DPoP draft at >> https://tools.ietf.org/html/draft-fett-oauth-dpop-00 >> >> Abstract >> >> This document defines a sender-constraint mechanism for OAuth 2.0 >> access tokens and refresh tokens utilizing an application-level >> proof-of-possession mechanism based on public/private key pairs. >> >> >> Thanks for the feedback I received so far from John, Mike, Torsten, and >> others during today's session or before! >> >> If you find any errors I would welcome if you open an issue in the GitHub >> repository at https://github.com/webhamster/draft-dpop >> >> - Daniel >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > * [OAUTH-WG] draft-fett-oauth-dpop-00   Daniel Fett * Re: [OAUTH-WG] draft-fett-oauth-dpop-00   Mike Jones * Re: [OAUTH-WG] draft-fett-oauth-dpop-00   Ludwig Seitz * Re: [OAUTH-WG] draft-fett-oauth-dpop-00   Filip Skokan * Re: [OAUTH-WG] draft-fett-oauth-dpop-00   Filip Skokan --------------46E49D4BA1A3851FC79DC78D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Speaking for myself, as a long time user of OAuth 2.0, I am very enthusiastic
    about the new proposal:
      "OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer"
      https://tools.ietf.org/html/draft-fett-oauth-dpop-00

    I believe it represents a real milestone for OAuth in that it appears to me
    to be the first proposal that is capable of offering true end-to-end integrity
    by using the OAuth 2.0 protocol at the application layer.

    In addition to the basic proof of possession capability, it inherently contains
    the mechanism for the client to completely protect any request that can be
    decomposed into a set of key:value pairs, which can then be signed within a JWT.

    The additional key:value pairs can be included in a Resource Access POST request,
    as described in section 5, by placing them in a 2nd JWT using the same public key
    and format as Figure 3, in a parameter with a name required by the Resource
    Server Application, for example, "dpop_appl_request".

    Since the parameter will be in the body of a POST request, there should be no size
    limitation for the set of key:value pairs that can be provided.

    Furthermore, the Access Token received in response to the token request shown
    in Figure 3, should cover the "dpop_appl_request" parameter, in the same way
    it covers the "dpop_proof" parameter described in section 5, because it covers
    the usage of the public key, and any specific content that is protected by that public key.

    The Access Token implicitly contains the user consent, the authorization of the IdP,
    plus the public key of the client making the request, and therefore the "dpop_appl_request"
    can potentially be usable to preserve the signature and possibly be used in some cases
    for non-repudiation, a capability that is not possible using the transport layer protocols,
    which remove all the protocol protection before delivering the request to the Resource Server Appl.

    In summary, the dpop at the appl layer proposal, imo, represents a significant advance in
    OAuth 2.0 technology that potentially addresses many of the security requirements
    that OAuth 2.0 does not currently provide.

      Thanks,
      Rich Levinson



    Re: [OAUTH-WG] draft-fett-oauth-dpop-00

    Filip Skokan <panva.ip@gmail.com> Fri, 29 March 2019 16:39 UTCShow header

    And here's a real simple client-side implementation using

- Webcrypto API
- IndexedDB API
- fetch

https://boiling-escarpment-16732.herokuapp.com/

It's not really a SPA but uses the same browser APIs and no backend other
than a web server hosting the html.

Best,
*Filip Skokan*


On Thu, 28 Mar 2019 at 19:48, Filip Skokan <panva.ip@gmail.com>; wrote:

> Hello Daniel, everyone,
>
> I've hacked together an AS implementation to enable client-side
> experimentation using this draft.
>
> You can find this hosted at https://draft-fett-oauth-dpop-00.herokuapp.com (it's
> also the issuer identifier). There's a default client registered and
> dynamic registration is also open, so hack away. It's using the draft
> version with dpop_binding expecting "jwk": { ...jwk } rather then "cnf": {
> "dpop+jwk": { ... jwk } } as the payload claim as suggested by Ludwig.
>
> There are more notes on the index page itself.
>
> Aaron kindly accepted to work on the SPA client-side demonstration, I'm
> not a SPA guru mastermind like Aaron and it would take me ages to deliver
> that particular piece. That being said I did test this with a regular web
> app as well as a CLI client using both code+pkce and dynamic port binding
> as well as device authorization grant client. Works.
>
> Feeding back to the draft
>
>    - i think we should mention the client to provide reasonable
>    expiration value of the dpop JWTs (max minutes). Altho not critical since
>    we require a jti, as an AS i don't wanna cache the used jti values forever
>    :)
>    - the AS should error when the dpop JWT contains private key material
>    - altho implied by the use of "public" and "private" key i think it
>    wouldn't hurt explicitly forbidding "oct" JWKs
>    - i don't see a point in dpop_proof containing the JWK again unless
>    the AS is supposed to do something new with it
>    - it wouldn't hurt mentioning that, kinda following 6750, when
>    dpop_proof is sent it's in a query for GET, in the request body for a POST.
>    my provider for instance will ignore query parameters during a POST. With
>    that said, what about RS endpoints using other methods? Maybe placing the
>    proof in a header isn't a terrible idea afterall.
>
>
> Kind Regards,
> *Filip Skokan*
>
>
> On Thu, 28 Mar 2019 at 11:19, Daniel Fett <danielf+oauth@yes.com>; wrote:
>
>> Hi all,
>>
>> I published the first version of the DPoP draft at
>> https://tools.ietf.org/html/draft-fett-oauth-dpop-00
>>
>> Abstract
>>
>>    This document defines a sender-constraint mechanism for OAuth 2.0
>>    access tokens and refresh tokens utilizing an application-level
>>    proof-of-possession mechanism based on public/private key pairs.
>>
>>
>> Thanks for the feedback I received so far from John, Mike, Torsten, and
>> others during today's session or before!
>>
>> If you find any errors I would welcome if you open an issue in the GitHub
>> repository at https://github.com/webhamster/draft-dpop
>>
>> - Daniel
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
    --------------46E49D4BA1A3851FC79DC78D--