From nobody Tue Jul 3 09:04:03 2018 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 1003A130F04; Tue, 3 Jul 2018 09:00:21 -0700 (PDT) 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.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063362105.4893.8587880355580612205.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:21 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 102 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:31 -0000 Dear Hannes Tschofenig, 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) Tuesday, 17 July 2018, Afternoon Session II 1550-1820 Room Name: Van Horne size: 130 --------------------------------------------- oauth Session 2 (1:30 requested) Thursday, 19 July 2018, Morning Session I 0930-1200 Room Name: Van Horne size: 130 --------------------------------------------- Special Note: 1550 - 1720 iCalendar: https://datatracker.ietf.org/meeting/102/sessions/oauth.ics Request Information: --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: secevent teep suit core tls ace sipcore acme tokbind People who must be present: Eric Rescorla Hannes Tschofenig Rifaat Shekh-Yusef Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jul 3 12:46:23 2018 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 7617E130DFB for ; Tue, 3 Jul 2018 12:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 J4US2OAP8qut for ; Tue, 3 Jul 2018 12:46:17 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10070.outbound.protection.outlook.com [40.107.1.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C2D130DF6 for ; Tue, 3 Jul 2018 12:46:16 -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=lEJckt8PNrEiRz0rLqCvbpQpHIfQ/DRL3VI7038N82o=; b=f6178OVu6Q7QsEkPubm/4RShbEM0pjSmgrQ0+pkPPLM5pujvD1U6l0U1VsOSU1/yWx8F+QXVO0cWnVla4tP7vzOk0ddOcpopyrjVsTi3kX2PeSrE36Rgx2d1ZhvE1X4yq0PZulo5jn9mf5kKKKDZ5GLBbmPRzCeRYR0kJljH2+s= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1518.eurprd08.prod.outlook.com (10.167.210.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.26; Tue, 3 Jul 2018 19:46:13 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0906.026; Tue, 3 Jul 2018 19:46:13 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: PoP Key Distribution Thread-Index: AdQTBj47ZlOcOW2pSHSpIBiWadk6Fg== Date: Tue, 3 Jul 2018 19:46:12 +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.118.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1518; 7:qz2rSRDk+XOvKr/ph/Dspw+8/mmbDT6e1c+MfLnVqUWmPeHlYR3BV2D32KHYXZffg2lvHCw+uvMzVoYkcMoiap/O8h8+e5zRZENqH3Ku/f9rOT0/AUFwO1Hy/pM/Xc0qWmh5m2xELIBpAUVvQ9G3OoDec/pTYMLn31E93nFusGaGyrEZEEF7RI1fW1852gMwp9xdADiwsyXLfGlmMoVOImMmND52VelnIlC8dtiK43fwB6Of86KuMSD9hB/t8ZIt x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 95f724c6-a04d-46d8-eefb-08d5e11da1ff x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1518; x-ms-traffictypediagnostic: VI1PR0801MB1518: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1518; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1518; x-forefront-prvs: 0722981D2A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(39860400002)(346002)(366004)(396003)(199004)(40434004)(53754006)(189003)(7696005)(72206003)(26005)(2906002)(6916009)(478600001)(2351001)(186003)(6506007)(81156014)(68736007)(5630700001)(3480700004)(55016002)(86362001)(966005)(5250100002)(54896002)(14454004)(6306002)(476003)(236005)(6436002)(102836004)(9686003)(8676002)(486006)(99286004)(8936002)(1730700003)(3846002)(5640700003)(33656002)(790700001)(74316002)(105586002)(2501003)(106356001)(7736002)(97736004)(606006)(5660300001)(6116002)(66066001)(2900100001)(25786009)(81166006)(316002)(7116003)(14444005)(5024004)(256004)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1518; 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-microsoft-antispam-message-info: 7O5VJB8dNo6YmaBfLVKd3lWuW3MQ9J6vj/19lFnvhEyI2EPs9el5e41VJD8MWdPPfP3edr1rxPWfrQI8Tao1iy8rIV4XOXGrrLFusMopMZRBSXvT9mG/F5JN1eP9p3LivU5hSUdeLS7PMXeEO7UU/2OdmVEPBjQ1X8dgg3O87L/vnf/sTvehxHgeYQpz56vHgB6lKKQJUEeC3+mAjI9AcgBq0dS3vIGoDCQIELUll6UVL0OyQI2IRdH8lvIssvVngIsR+S/+9hYXjpCURDFuVnmf+Luys9k25ukoGOqmpG02G7S5HqO7ScB7OlXEgVHCoNRCqPzw0IUD0xRYBj+ERvPbRXAvtVyGRwgOIXBjYf4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211213D11E7820FD31218663FA420VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95f724c6-a04d-46d8-eefb-08d5e11da1ff X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2018 19:46:12.9848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1518 Archived-At: Subject: [OAUTH-WG] PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 19:46:21 -0000 --_000_VI1PR0801MB211213D11E7820FD31218663FA420VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, we have been working on an update for the draft-ietf-oauth-pop-key-distribu= tion document in time for the deadline but we noticed several issues that a= re worthwhile to bring to your attention. draft-ietf-oauth-pop-key-distribution defines a mechanism that allows the c= lient to talk to the AS to request a PoP access token and associated keying= material. There are two other groups in the IETF where this concept is used. =B7 The guys working on RTCWEB is the first. Misi (M=E9sz=E1ros Mih= =E1ly) has been helping us to understand their needs. They have defined the= ir own token format, which has been posted on the OAuth group a while ago f= or review. =B7 The other group is ACE with their work on an OAuth-based profil= e for IoT. Where should the parameters needed for PoP key distribution should be defin= ed? Currently, they are defined in two places -- in https://tools.ietf.org/= html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/= draft-ietf-oauth-pop-key-distribution-03. In particular, the audience and t= he token_type parameters are defined in both specs. IMHO it appears that OAuth would be the best place to define the HTTP-based= parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, = and alike. Of course, this is subject for discussion, particularly if there= is no interest in doing so in the OAuth working group. There is also a misalignment in terms of the content. draft-ietf-oauth-pop-= key-distribution defined an 'alg' parameter, which does not exist in the dr= aft-ietf-ace-oauth-authz document. The draft-ietf-ace-oauth-authz document = does, however, have a profile parameter, which does not exist in draft-ietf= -oauth-pop-key-distribution. Some alignment is therefore needed. In the mea= nwhile the work on OAuth meta has been finalized and could potentially be r= e-used. When the work on draft-ietf-oauth-pop-key-distribution was initially starte= d there was only a single, standardized token format, namely the JWT. Hence= , it appeared reasonable to use the JWT keying structure for delivering key= ing material from the AS to the client. In the meanwhile two other formats have been standardized, namely RFC 7635 = and the CWT. For use with those specs it appears less ideal to transport ke= ys from the AS to the client using the JSON/JOSE-based format. It would be = more appropriate to use whatever PoP token format is used instead. Currentl= y, this hasn't been considered yet. 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_VI1PR0801MB211213D11E7820FD31218663FA420VI1PR0801MB2112_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

we have been working on an update for the draft-ietf= -oauth-pop-key-distribution document in time for the deadline but we notice= d several issues that are worthwhile to bring to your attention.

 

draft-ietf-oauth-pop-key-distribution defines a mech= anism that allows the client to talk to the AS to request a PoP access toke= n and associated keying material.

 

There are two other groups in the IETF where this co= ncept is used.

 

=B7         The guys working on RTCWEB is the first. Mis= i (M=E9sz=E1ros Mih=E1ly) has been helping us to understand their needs. Th= ey have defined their own token format, which has been posted on the OAuth = group a while ago for review.

 

=B7         The other group is ACE with their work on an= OAuth-based profile for IoT.

 

Where should the parameters needed for PoP key distr= ibution should be defined? Currently, they are defined in two places -- in https= ://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03<= /a>. In particular, the audience and the token_type parameters are defined = in both specs.

 

IMHO it appears that OAuth would be the best place t= o define the HTTP-based parameters. ACE could define the IoT-based protocol= s, such as CoAP, MQTT, and alike. Of course, this is subject for discussion= , particularly if there is no interest in doing so in the OAuth working group.

 

There is also a misalignment in terms of the content= . draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which d= oes not exist in the draft-ietf-ace-oauth-authz document. The draft-ietf-ac= e-oauth-authz document does, however, have a profile parameter, which does not exist in draft-ietf-oauth-pop-key= -distribution. Some alignment is therefore needed. In the meanwhile the wor= k on OAuth meta has been finalized and could potentially be re-used.

 

When the work on draft-ietf-oauth-pop-key-distributi= on was initially started there was only a single, standardized token format= , namely the JWT. Hence, it appeared reasonable to use the JWT keying struc= ture for delivering keying material from the AS to the client.

 

In the meanwhile two other formats have been standar= dized, namely RFC 7635 and the CWT. For use with those specs it appears les= s ideal to transport keys from the AS to the client using the JSON/JOSE-bas= ed format. It would be more appropriate to use whatever PoP token format is used instead. Currently, this hasn't b= een considered yet.

 

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_VI1PR0801MB211213D11E7820FD31218663FA420VI1PR0801MB2112_-- From nobody Tue Jul 3 13:11:10 2018 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 12C04130FF3 for ; Tue, 3 Jul 2018 13:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 KGrPGLQPKu4n for ; Tue, 3 Jul 2018 13:10:55 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640122.outbound.protection.outlook.com [40.107.64.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C060130E75 for ; Tue, 3 Jul 2018 13:10:54 -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=BLjmhdayb/bcp1eK1iBk3VVbtyoFBL1LOt3JOE2Nf+k=; b=c1I0n/9Rpf670BuNLczFWQh5LwItZ3/IIS3XukqTPDYieiGjobD4U9reZqjGylrkKbv4CNA04dficUjxfL9Oi4Hed8c1zysb9cmrIm9cMJrdZ+scw3Ztgtyc85hPDBwHLd5n7NZYzPW+PyfF1vEqWLKVvXGpsq83GOFbeCsvisE= Received: from DM5PR00MB0293.namprd00.prod.outlook.com (52.132.128.34) by DM5PR00MB0438.namprd00.prod.outlook.com (52.132.129.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.967.0; Tue, 3 Jul 2018 20:10:52 +0000 Received: from DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::4585:e342:2207:ca93]) by DM5PR00MB0293.namprd00.prod.outlook.com ([fe80::4585:e342:2207:ca93%4]) with mapi id 15.20.0967.000; Tue, 3 Jul 2018 20:10:52 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: PoP Key Distribution Thread-Index: AdQTBj47ZlOcOW2pSHSpIBiWadk6FgAA3/bg Date: Tue, 3 Jul 2018 20:10:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0438; 6:6bk1n0sAd5r0GwUPvqTOivJPtKccvRyIrPOUwgJJstYxzJN0GWEsB11KqaAVzjXGR0YJizAt2um09qsBKWI0DhtX25unnLdh9KchJMApW/fAeWiF/MJieXciH2ET/UTpWxBJn7H6xkGlIx96sdVymN5n3/gpiBrSnMH6k19IImmsTLoerzW/KJ0NdyZIKZLo9//coQ0OsNLHUFGAAz5lGf8hLzD3ONRtTtsMBc2ceQWp2pCx95OQizbchumUSZqd7AWhChM3XAvk4jNnSHAVF55pd9zO2ykFuhewdNGhxAAo5WVzV81o/yxabEw9jZwA6nEZJLShwOXF3j6VkSpPchQEB4SdAmPig9r86XLigllv4rObP2LV/8Zq5ZWZxRIMiT7EpjQt/5PEb4hOjYYKiLDrXZYS8REPziOucGX2U5BueFIXXjcRv3EqE3wf/G19n3eDMNwR2UfRoXabdyV/lw==; 5:9O+ew5dyVUjLl4/Ig9wKzylSMDefY2wfJBI97kFbIPgNKEpmdR+dM+Zlt5byHKwvlGst3DJsvuw4CKFD/TyaMwgb5sydNmNxjLjXjDiwLok1OtBIJqUZHbBcIowFfh5xckGMe1POkiQPnLqCRGQcYso/zVzJQAnZyx/bPS72W70=; 7:gZdFQXbkoJmV/AbDXXcrMB5zGElrtDSSMvn3F13VnHs5JBA4LGvG5PVls/HHkRE5O/itwDe16/qVijjIAkPxa9/4iih3Me7aMMJE9LGczMzEJ3vwB+A5nA+3w27okdVO6M6EZuFrm1lRvUx7BS/QXdyQ1sAdUuEG2t3LRO5l5juPCnNbDinZYPjmC+Q34iLTECuHPT397OM0Tdo7UvjAF+ygnBMSjGBBehmadmG6uRqd2yYQm5UovxHb2Js49k1v x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 11157406-f59d-4e64-ed35-08d5e12113f4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:DM5PR00MB0438; x-ms-traffictypediagnostic: DM5PR00MB0438: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(3231280)(2018427008)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DM5PR00MB0438; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0438; x-forefront-prvs: 0722981D2A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(136003)(396003)(376002)(366004)(53754006)(40434004)(189003)(199004)(8936002)(81166006)(10290500003)(790700001)(81156014)(3480700004)(8676002)(97736004)(86612001)(5250100002)(478600001)(68736007)(6116002)(3846002)(7736002)(6506007)(6246003)(53546011)(25786009)(8990500004)(256004)(6436002)(5024004)(14444005)(66066001)(102836004)(10090500001)(53936002)(76176011)(229853002)(7696005)(86362001)(99286004)(186003)(26005)(6306002)(11346002)(446003)(14454004)(9686003)(22452003)(105586002)(316002)(55016002)(2906002)(966005)(106356001)(72206003)(74316002)(7116003)(476003)(5660300001)(2900100001)(19609705001)(2501003)(486006)(236005)(54896002)(110136005)(606006)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0438; H:DM5PR00MB0293.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) x-microsoft-antispam-message-info: vniEqEMGgacEMeVdbsWA/2m/S3wL9DyerQ1Y1FiOTbfV7w7I1ZrkX/b7LdULkbzvYTEXWba52njtIjqOyrFsk5O6cdmeLXEErOLXquCAWPBunI2snp4n1YWKgfjXNwhRnNYBf8StQbe3k05Ihz/GZTznaeAoSjpLlWz6lgZCWNe0VOaduKtcVykMBGaYtVnMfJtoPrYb2/ZQkMzsLdcPb1IGUobrcldWmHC92leuoJBYa1cxH/BmwiNAU3iuAv7TuKNvTDpBSf3nceEMiNJoe8meMkQRQr9gvWaN5VNJUzPlWfOde+HHp68cqG6klWRll7Jedet9Xr5Zmzhp6OApMOpeqqJooeo312PbUgeJHrg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB029359EBBE81D3899BEA34FBF5420DM5PR00MB0293namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11157406-f59d-4e64-ed35-08d5e12113f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2018 20:10:52.6641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0438 Archived-At: Subject: Re: [OAUTH-WG] PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 20:11:08 -0000 --_000_DM5PR00MB029359EBBE81D3899BEA34FBF5420DM5PR00MB0293namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for working these issues, Hannes. I agree with your conclusion that= the OAuth PoP Key Distribution spec should define the OAuth parameters for= use with HTTP and the ACE OAuth profile should define those that are ACE-s= pecific. Therefore, we should encourage ACE spec to remove the duplicate d= efinitions and instead reference those in the OAuth spec. I believe that the ACE "profile" parameter is typically unnecessary and not= in the spirit of normal OAuth. Configuration information between OAuth pa= rticipants is typically configured out of band and/or retrieved from the AS= Discovery document (per the newly minted RFC 8414). There's no need to dynamically exchange a profile identifier= when this is essentially always known in advance. We should not include "= profile". For that matter, ACE should delete it as well, as it certainly i= sn't appropriate in constrained environments. We should think some more about how we want to treat the function of the "a= lg" parameter and how to fully specify things for JWTs (an OAuth WG spec) w= hile still enabling other representations when appropriate. Thanks, -- Mike From: OAuth On Behalf Of Hannes Tschofenig Sent: Tuesday, July 3, 2018 12:46 PM To: oauth@ietf.org Subject: [OAUTH-WG] PoP Key Distribution Hi all, we have been working on an update for the draft-ietf-oauth-pop-key-distribu= tion document in time for the deadline but we noticed several issues that a= re worthwhile to bring to your attention. draft-ietf-oauth-pop-key-distribution defines a mechanism that allows the c= lient to talk to the AS to request a PoP access token and associated keying= material. There are two other groups in the IETF where this concept is used. * The guys working on RTCWEB is the first. Misi (M=E9sz=E1ros Mih=E1ly)= has been helping us to understand their needs. They have defined their own= token format, which has been posted on the OAuth group a while ago for rev= iew. * The other group is ACE with their work on an OAuth-based profile for = IoT. Where should the parameters needed for PoP key distribution should be defin= ed? Currently, they are defined in two places -- in https://tools.ietf.org/= html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/= draft-ietf-oauth-pop-key-distribution-03. In particular, the audience and t= he token_type parameters are defined in both specs. IMHO it appears that OAuth would be the best place to define the HTTP-based= parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, = and alike. Of course, this is subject for discussion, particularly if there= is no interest in doing so in the OAuth working group. There is also a misalignment in terms of the content.. draft-ietf-oauth-pop= -key-distribution defined an 'alg' parameter, which does not exist in the d= raft-ietf-ace-oauth-authz document. The draft-ietf-ace-oauth-authz document= does, however, have a profile parameter, which does not exist in draft-iet= f-oauth-pop-key-distribution. Some alignment is therefore needed. In the me= anwhile the work on OAuth meta has been finalized and could potentially be = re-used. When the work on draft-ietf-oauth-pop-key-distribution was initially starte= d there was only a single, standardized token format, namely the JWT. Hence= , it appeared reasonable to use the JWT keying structure for delivering key= ing material from the AS to the client. In the meanwhile two other formats have been standardized, namely RFC 7635 = and the CWT. For use with those specs it appears less ideal to transport ke= ys from the AS to the client using the JSON/JOSE-based format. It would be = more appropriate to use whatever PoP token format is used instead. Currentl= y, this hasn't been considered yet. 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_DM5PR00MB029359EBBE81D3899BEA34FBF5420DM5PR00MB0293namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for working the= se issues, Hannes.  I agree with your conclusion that the OAuth PoP Ke= y Distribution spec should define the OAuth parameters for use with HTTP an= d the ACE OAuth profile should define those that are ACE-specific.  Therefore, we should encourage ACE spec to re= move the duplicate definitions and instead reference those in the OAuth spe= c.

 

I believe that the ACE= “profile” parameter is typically unnecessary and not in the sp= irit of normal OAuth.  Configuration information between OAuth partici= pants is typically configured out of band and/or retrieved from the AS Discovery document (per the newly minted RFC 8414). There’s no need to dynamically exchange a profile iden= tifier when this is essentially always known in advance.  We should no= t include “profile”.  For that matter, ACE should delete i= t as well, as it certainly isn’t appropriate in constrained environments.

 

We should think some m= ore about how we want to treat the function of the “alg” parame= ter and how to fully specify things for JWTs (an OAuth WG spec) while still= enabling other representations when appropriate.

 

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

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

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Tuesday, July 3, 2018 12:46 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] PoP Key Distribution

 

Hi all,

 

we have been working on an upda= te for the draft-ietf-oauth-pop-key-distribution document in time for the d= eadline but we noticed several issues that are worthwhile to bring to your = attention.

 

draft-ietf-oauth-pop-key-distri= bution defines a mechanism that allows the client to talk to the AS to requ= est a PoP access token and associated keying material.

 

There are two other groups in t= he IETF where this concept is used.

 

  • The guys working on RTCWEB is the first. Misi (M= =E9sz=E1ros Mih=E1ly) has been helping us to understand their needs. They h= ave defined their own token format, which has been posted on the OAuth group a while ago for review. <= /li>

 

  • The other group is ACE with their work on an OAu= th-based profile for IoT.

 

Where should the parameters nee= ded for PoP key distribution should be defined? Currently, they are defined= in two places -- in https= ://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03<= /a>. In particular, the audience and the token_type parameters are defined = in both specs.

 

IMHO it appears that OAuth woul= d be the best place to define the HTTP-based parameters. ACE could define t= he IoT-based protocols, such as CoAP, MQTT, and alike. Of course, this is s= ubject for discussion, particularly if there is no interest in doing so in the OAuth working group.

 

There is also a misalignment in= terms of the content.. draft-ietf-oauth-pop-key-distribution defined an 'a= lg' parameter, which does not exist in the draft-ietf-ace-oauth-authz docum= ent. The draft-ietf-ace-oauth-authz document does, however, have a profile parameter, which does not exist in = draft-ietf-oauth-pop-key-distribution. Some alignment is therefore needed. = In the meanwhile the work on OAuth meta has been finalized and could potent= ially be re-used.

 

When the work on draft-ietf-oau= th-pop-key-distribution was initially started there was only a single, stan= dardized token format, namely the JWT. Hence, it appeared reasonable to use= the JWT keying structure for delivering keying material from the AS to the client.

 

In the meanwhile two other form= ats have been standardized, namely RFC 7635 and the CWT. For use with those= specs it appears less ideal to transport keys from the AS to the client us= ing the JSON/JOSE-based format. It would be more appropriate to use whatever PoP token format is used instead. Curr= ently, this hasn't been considered yet.

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immedia= tely and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

--_000_DM5PR00MB029359EBBE81D3899BEA34FBF5420DM5PR00MB0293namp_-- From nobody Tue Jul 3 23:37:22 2018 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 4B82E130EB4 for ; Tue, 3 Jul 2018 23:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 smBhYxUJrOpm for ; Tue, 3 Jul 2018 23:37:17 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.36]) (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 A10EB130DD7 for ; Tue, 3 Jul 2018 23:37:17 -0700 (PDT) Received: from 1fabPf-000S0l-TD by out11d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fabPf-000S1w-U1 for oauth@ietf.org; Tue, 03 Jul 2018 23:37:15 -0700 Received: by emcmailer; Tue, 03 Jul 2018 23:37:15 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fabPf-000S0l-TD for oauth@ietf.org; Tue, 03 Jul 2018 23:37:15 -0700 Received: from [192.168.0.166] (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.1466.3; Wed, 4 Jul 2018 08:37:14 +0200 To: References: From: Ludwig Seitz Message-ID: <67ab6c51-4299-b433-01f0-cd023574175a@ri.se> Date: Wed, 4 Jul 2018 08:37:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [OAUTH-WG] PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 06:37:21 -0000 On 2018-07-03 22:10, Mike Jones wrote: > > I believe that the ACE “profile” parameter is typically unnecessary and > not in the spirit of normal OAuth.  Configuration information between > OAuth participants is typically configured out of band and/or retrieved > from the AS Discovery document (per the newly minted RFC 8414 > ). There’s no need to dynamically > exchange a profile identifier when this is essentially always known in > advance.  We should not include “profile”.  For that matter, ACE should > delete it as well, as it certainly isn’t appropriate in constrained > environments. > I strongly disagree with this statement. First of all let me correct a misconception you seem to have: RFC 8414 is about AS metadata, while "profile" is RS metadata, so unless I've overlooked something, RFC 8414 is not applicable. The "profile" parameter tells a client which communication security method to use with the RS (e.g. TLS) and how to perform the proof-of-possession of a token towards an RS (e.g. TLS client authentication). When you take the work on proof-of-possession into account, that feels very much in the spirit of OAuth. Second: the "profile" parameter is optional, so if it is already known because it was configured out of band or discovered somehow you just don't send it. Finally: Profile is intended for use cases were mobile clients and RS dynamically join and leave a network, so that pre-configuring clients with metadata about the RS is difficult. Do you have a better idea how to solve these cases? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue Jul 3 23:55:57 2018 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 8018C130E3C for ; Tue, 3 Jul 2018 23:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 UcZm3-QFh-ln for ; Tue, 3 Jul 2018 23:55:52 -0700 (PDT) Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.36]) (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 D5E4D120049 for ; Tue, 3 Jul 2018 23:55:51 -0700 (PDT) Received: from 1fabhb-000EJJ-Ti by out10b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fabhb-000EKS-UY for oauth@ietf.org; Tue, 03 Jul 2018 23:55:47 -0700 Received: by emcmailer; Tue, 03 Jul 2018 23:55:47 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10b.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fabhb-000EJJ-Ti for oauth@ietf.org; Tue, 03 Jul 2018 23:55:47 -0700 Received: from [192.168.0.166] (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.1466.3; Wed, 4 Jul 2018 08:55:47 +0200 To: References: From: Ludwig Seitz Message-ID: <58eac9f9-21a6-aa6d-ac28-6fce70cfa08e@ri.se> Date: Wed, 4 Jul 2018 08:55:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [OAUTH-WG] PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 06:55:55 -0000 On 2018-07-03 21:46, Hannes Tschofenig wrote: > Hi all, > ... > Where should the parameters needed for PoP key distribution should be > defined? Currently, they are defined in two places -- in > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03. In > particular, the audience and the token_type parameters are defined in > both specs. > > IMHO it appears that OAuth would be the best place to define the > HTTP-based parameters. ACE could define the IoT-based protocols, such as > CoAP, MQTT, and alike. Of course, this is subject for discussion, > particularly if there is no interest in doing so in the OAuth working > group. > I fully agree that OAuth would be the best place. I've only drawn some of these parameters into draft-ietf-ace-oauth-authz because the work on draft-ietf-oauth-pop-key-distribution seemed to have been discontinued (it expired August 2017). That said, I'd hate to introduce a normative dependency into draft-ietf-ace-oauth-authz on a document that will not move forward or only move very slowly. What are the prospects of going forward quickly with draft-ietf-oauth-pop-key-distribution? > There is also a misalignment in terms of the content.. > draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which > does not exist in the draft-ietf-ace-oauth-authz document. The > draft-ietf-ace-oauth-authz document does, however, have a profile > parameter, which does not exist in > draft-ietf-oauth-pop-key-distribution. Some alignment is therefore > needed. In the meanwhile the work on OAuth meta has been finalized and It seems indeed that 'alg' and 'profile' parameters have some overlap, although 'alg' seemed a bit more narrow to me (which is why I created 'profile'). If we could extend the definition of 'alg' a bit, I'd be OK to remove 'profile' from the ACE draft (provided the OAuth draft moves forward in a timely manner). /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Wed Jul 4 14:47:08 2018 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 7ADC5130E13 for ; Wed, 4 Jul 2018 14:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YrQejCfj93vc for ; Wed, 4 Jul 2018 14:47:03 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 8EC51131048 for ; Wed, 4 Jul 2018 14:47:03 -0700 (PDT) X-AuditID: 1209190e-4e1ff70000006518-b4-5b3d40565253 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 99.1B.25880.6504D3B5; Wed, 4 Jul 2018 17:47:02 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w64Ll0QZ022698; Wed, 4 Jul 2018 17:47:01 -0400 Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id w64LkvkE005963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jul 2018 17:46:59 -0400 Date: Wed, 4 Jul 2018 16:46:57 -0500 From: Benjamin Kaduk To: Mike Jones Cc: "oauth@ietf.org" Message-ID: <20180704214654.GK60996@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrRvmYBttcOq2lEXDl9VMFiffvmJz YPI4sewKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJ6dl9gK1jJWbFn4k22BsZz7F2MHBwSAiYS h87ldjFycQgJLGaSmN7YxgjhbGCU6Fy0iQnCucIkcXzRTpYuRk4OFgEViebt79lBbDYgu6H7 MjOILSJgK/H70F6wGmYBVYkvC94zgdjCAjoSjzbeB4vzAm17d2MbG4gtJLCZUeLmDWuIuKDE yZlPoHq1JG78e8kEch2zgLTE8n8cIGFOgViJ7i37wFpFBZQl9vYdYp/AKDALSfcsJN2zELoX MDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3ECA5SSb4djJMavA8xCnAwKvHw 3jhtEy3EmlhWXJl7iFGSg0lJlFd+o3W0EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFeVXHbaCHe lMTKqtSifJiUNAeLkjhv9iLGaCGB9MSS1OzU1ILUIpisDAeHkgSvkz1Qo2BRanpqRVpmTglC momDE2Q4D9Dw+3Ygw4sLEnOLM9Mh8qcYdTn+vJ86iVmIJS8/L1VKnJcDZJAASFFGaR7cHFBy kcjeX/OKURzoLWHeQJAqHmBigpv0CmgJE9CSnm2WIEtKEhFSUg2MhzO+7Ulj3sutV5n9Jotv Z9Oy074TNnc9O9F36r/S8nnCMyeKhzWcVbkfMuNKe2MUW863gDityL2/5LziPHLtOKd+mCGg blz275/iZFFWEYGmVSJK70Iu2rw+psH04IbbP4dL09+lHQhetHwPv2/YLJkrH1t2aGh5hntV nfeYc2CXot8i6V1HlFiKMxINtZiLihMBMymktQkDAAA= Archived-At: Subject: Re: [OAUTH-WG] PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 21:47:07 -0000 On Tue, Jul 03, 2018 at 08:10:52PM +0000, Mike Jones wrote: > > I believe that the ACE "profile" parameter is typically unnecessary and > not in the spirit of normal OAuth. Configuration information between > OAuth participants is typically configured out of band and/or retrieved > from the AS Discovery document (per the newly minted RFC > 8414). There's no need to > dynamically exchange a profile identifier when this is essentially always > known in advance. We should not include "profile". For that matter, ACE For what it's worth, this part of "the spirit of normal OAuth" is something that leaves me with lingering unease. While I do not dispute that this sort of configuration information is usually known out of band or via discovery, we ought to be considering the potential consequences when the parties do not actually agree on what configuration should be in use. An explicit indicator makes for an easy-to-analyze "fail quickly" scenario, whereas leaving things implicit is much harder to reason about. And yes, this case of easier analysis is at the cost of complexity elsewhere, so there is a tradeoff. -Ben From nobody Thu Jul 5 08:02:36 2018 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 46FCB130DE5 for ; Thu, 5 Jul 2018 08:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_DKIMWL_WL_HIGH=-0.01] 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 kUnrY4WzJ0su for ; Thu, 5 Jul 2018 08:02:31 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640091.outbound.protection.outlook.com [40.107.64.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEB6130E84 for ; Thu, 5 Jul 2018 08:02:31 -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=eBhhyf9xdv7SfvytW5d3HIjsU5N1TusxBfAa2BzEkuE=; b=CHSZsEBtasLRGwwRCKQxE5xv5YRazDR3Dd532/Wdbs7l+qFwGK5UtddilPu0cBQc2ka7JnzE0oboxS8rJ0CmwmjtgMMG1LXSnC+S8xvX94ihKmIaXkOtblNYMthP//XErWgzv415b16zpFdNzvdL7JbDqeAT/GpvZxKSwSb2cuY= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0378.namprd00.prod.outlook.com (52.132.148.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.967.0; Thu, 5 Jul 2018 15:02:29 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::9c24:5ebc:cf1a:dc37]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::9c24:5ebc:cf1a:dc37%6]) with mapi id 15.20.0971.000; Thu, 5 Jul 2018 15:02:29 +0000 From: Mike Jones To: Ludwig Seitz , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] PoP Key Distribution Thread-Index: AdQTBj47ZlOcOW2pSHSpIBiWadk6FgAA3/bgABXsJYAAQ7FFYA== Date: Thu, 5 Jul 2018 15:02:29 +0000 Message-ID: References: <67ab6c51-4299-b433-01f0-cd023574175a@ri.se> In-Reply-To: <67ab6c51-4299-b433-01f0-cd023574175a@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0378; 6:gywdvnl8qmrverDAJp51BuXS8onZhG5M6YYjf/tLlTRWOE/xgAxB8m5050LRmeql2MeZZQiTXf6Mwm7u0ddhqSXhl06aajgE+OX3dT2m+vLwwre+I2lukEUE3ArAWsHBGB0Edb5GKLFk+/s8QVTERFYCY/W+9WhJuzzHLPh51lxRR41tGvwY2WgotECFMqlMdNpxDdbm3Q4/AkuoWEyjlksedvNN2/PLRxGOK0/OV5D3wYqu3+JKsfn2z+1iRVdtwjBl+LG04ihOmFOEvoS9kWHeKudkhsFxoUb9XIYzRvoN9kp4iF9ogOQ+CZp0PiqdogQ9GZTC4hlxYj7LPXP+biM6wc2ejvSN4SS1uulegmRELP/1tyDl2JbmQNN1DwIWNz5ZVW4y8E8HUjz7QyGDS/pSGWvEkeWUKGV3OCCTC0Pta7XnmyzaL2daP08q4iiZq5cmrHcEnpQCVuSeO5cLyQ==; 5:oIFGZuBb9Qt/ITKv/bgwm7zxtc280DYSmG9nnBE0YgoIguIfuCgqrPzMIgq/M5Jm17azHhblVEQgBmJIaV9cseurGEhMpWiwaRgAl2KYXP6pXGyp4e6z7MVUtYShzVt23DYk6Ko0oVOJUjWTdhzJQzF/xToUh4TZ023kNnJXGkA=; 7:p4XpFWbv+K52KhZFeDW2m1aRAULJdo9EgqUCH7XJPqZMwyc0fhJ7xC7uoENwfyoW9EaB6Tm0FTYHhTMcrs+uPGuoXIhuHE2jPgFzBcT+C3SSOGEG1iuzaRm9kof1vEhNuzbKh0GSVgkBKQOip3H6y0ikFfuMPL94Fa9/YYUiGwcfJVY4MtjvnundqBLrcuzmeUPBRA7k+FKJA5WgniqI7Ddb98GU4biR+P5coO/+Uswt+R9Vi5R4ZJrUL5VA7RQw x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 091e92b6-1168-43cc-6cd9-08d5e28853ff x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:MW2PR00MB0378; x-ms-traffictypediagnostic: MW2PR00MB0378: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027023009)(20171027022009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(93006095)(93001095)(3231280)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MW2PR00MB0378; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0378; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(346002)(376002)(366004)(199004)(189003)(13464003)(7696005)(186003)(99286004)(53546011)(2900100001)(26005)(6506007)(8676002)(76176011)(6246003)(9686003)(55016002)(5660300001)(6436002)(446003)(486006)(74316002)(7736002)(5250100002)(102836004)(476003)(11346002)(2501003)(316002)(6306002)(86362001)(81166006)(22452003)(86612001)(305945005)(14444005)(110136005)(478600001)(8990500004)(33656002)(25786009)(966005)(2906002)(66066001)(72206003)(81156014)(10090500001)(8936002)(68736007)(14454004)(10290500003)(53936002)(3846002)(106356001)(229853002)(6116002)(105586002)(97736004)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0378; H:MW2PR00MB0298.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) x-microsoft-antispam-message-info: 0LUsbHWvAh63AiH6mMw8EC/XpA+OfzAgxYQ+qUBjQ1xsJHoeyCmV274Ldk852Ydo07v30nSzA8hQF87MfoXtND3E2+CcKaysNlEeq9uLOQEq06TEtLjeaunH3qxCoNF+lC7lZmeQ6+0BJ3hO8Y3oT+XWw1g6b5kKBHI1xtkKyLXdtfYWurEvLaTW4Pnkxbk3QqIm/bWB1Tz622S5gdc00urkvuevE4Ij0ZOhQnF4rdW5KwaLVymYEBcpXUzGz/YVYBf9vYGunLIcBBss1sr7/YB6VBvkD9X/GVTuD09fEPEATWMok+Q0vzQG6TOgBhvoCJzYPj4eb+EJz/mCmuQK4ak54RamJA4WRbsSigVCcvs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 091e92b6-1168-43cc-6cd9-08d5e28853ff X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 15:02:29.4320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0378 Archived-At: Subject: Re: [OAUTH-WG] PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 15:02:35 -0000 Hi Ludwig. You're right that AS Metadata doesn't cover RS Metadata. I sta= nd corrected on that point. There was once an OAuth Resource Metadata draf= t but the working group didn't have immediate use cases for it and so it wa= s allowed to expire. Work on it can resume, if it would be useful. I'm glad that "profile" is now optional in ACE. I still believe that dynam= ic configurations where clients might use multiple OAuth profiles are a cor= ner case and that purpose-built clients that have the profile information b= aked into the code will be the norm (particularly in constrained environmen= ts). I'm fine with an independent OAuth specification being created that d= efines a profile identifier but I believe that conflating this with OAuth P= oP Key Distribution would be a mistake. -- Mike -----Original Message----- From: OAuth On Behalf Of Ludwig Seitz Sent: Tuesday, July 3, 2018 11:37 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] PoP Key Distribution On 2018-07-03 22:10, Mike Jones wrote: >=20 > I believe that the ACE "profile" parameter is typically unnecessary=20 > and not in the spirit of normal OAuth.=A0 Configuration information=20 > between OAuth participants is typically configured out of band and/or=20 > retrieved from the AS Discovery document (per the newly minted RFC=20 > 8414 ). There's no need to=20 > dynamically exchange a profile identifier when this is essentially=20 > always known in advance.=A0 We should not include "profile".=A0 For that= =20 > matter, ACE should delete it as well, as it certainly isn't=20 > appropriate in constrained environments. > I strongly disagree with this statement. First of all let me correct a misc= onception you seem to have: RFC 8414 is about AS metadata, while "profile" = is RS metadata, so unless I've overlooked something, RFC 8414 is not applic= able. The "profile" parameter tells a client which communication security method = to use with the RS (e.g. TLS) and how to perform the proof-of-possession of= a token towards an RS (e.g. TLS client authentication). When you take the work on proof-of-possession into account, that feels very= much in the spirit of OAuth. Second: the "profile" parameter is optional, so if it is already known beca= use it was configured out of band or discovered somehow you just don't send= it. Finally: Profile is intended for use cases were mobile clients and RS dynam= ically join and leave a network, so that pre-configuring clients with metad= ata about the RS is difficult. Do you have a better idea how to solve these= cases? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jul 5 08:03:30 2018 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 B28F0130E7A for ; Thu, 5 Jul 2018 08:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_DKIMWL_WL_HIGH=-0.01] 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 ziWcoxEE6rKF for ; Thu, 5 Jul 2018 08:03:25 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640110.outbound.protection.outlook.com [40.107.64.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2A1130DED for ; Thu, 5 Jul 2018 08:03:24 -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=H9hG80EREEmLYOs8JExAu9AzkE+e3XZuOVYlRbSAMOw=; b=Sb8qz7iWbIyT3XsLMVTsmPaldM3y6uMRkhwbhJ3roPYQ5DoGN4np/jcrGuWjPdKQnHdHTmSoWkSw+kXnPiaxVFDHE79gXp4zRQc39sqRh5hGeGhVwuKKUKst4XXnvjlEAgtYurwb/pNcbkKtcnLu1Ha4cCeE0R2VQ3pGzkeeseI= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0378.namprd00.prod.outlook.com (52.132.148.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.967.0; Thu, 5 Jul 2018 15:03:23 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::9c24:5ebc:cf1a:dc37]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::9c24:5ebc:cf1a:dc37%6]) with mapi id 15.20.0971.000; Thu, 5 Jul 2018 15:03:23 +0000 From: Mike Jones To: Benjamin Kaduk CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] PoP Key Distribution Thread-Index: AdQTBj47ZlOcOW2pSHSpIBiWadk6FgAA3/bgADWyZIAAJC4Z4A== Date: Thu, 5 Jul 2018 15:03:23 +0000 Message-ID: References: <20180704214654.GK60996@kduck.kaduk.org> In-Reply-To: <20180704214654.GK60996@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0378; 6:YnCAIe783PdZANhlO0dmkXSFo0TLwATVAsNgyRpXcv32PF/t9zVfLkfWmaJojtl+SCEjB/xZyx6EV7QcpVB+rKhp2NC64M6EA4iaK/onS4cPf65QCYzGKXSD3sMIfJWuWbXGkF0pHfH58X8uIMxHvzSYsiWKZ4elp4OLpHnZDVW2JV6Vx/ldyz47ygRgZWqcX6ne8sFeVrGdvePZdyaWRZmlMVMtCPslCIFPsvM5ErRBCxOiuWUr77ptoY2nj5Sbh6HgWWswuklue0DmqQQpURRL9SxMVL8AWk3wMO3HluxZ1BFOkOwkmA3EO8PuRVnCVXmFtzeZzG7hZaiwfQ4QtUjnfqtDT5bZDezUmgtSLNfjJOG+nOE7BsUjeeOMrU2P214qyWuubyIGHqiz+VVCtzPC3R0M/3WLgsCD+PmCcV+4AXQAzcUJER1mKMAnPsaIIrmzntNPkspZRQDipkjMGQ==; 5:Fx0gSSt6BKS+RCYcZ8UuvBS4Annc6Uk8qOuYJIN/Do8EkYvGty3QhP8fooc+g5zgnctQejEVYEIQJF7SZxqraGwW0lG9wE59PZnraNiLQmrhqC9jZp1HuC/qXZKzk131qgjGB2FGQwjW+UMDiFvjMqgTKIfx/EffjOV23t5WGNA=; 7:9rL07k7xmgRW6AtStxqouGleiCHDgIa25hOKN783RSMXWh5yjbJlezWuqDlcpE4rm7cuZAEicCwyzzyTZk9KXpXTeUqWDtRZ9E7NGznH0nOxXPQIAMzokk7sN8Lh5rqKbcfSQtGGMaE1nOHt5PO64iI7pKDu+X+9gKeDXCNrJonK4tPs0e5pEmajZafoTXxU2Ni/9rGnOiqdMV7MNf8wE2VOiOPbO20OO2El9IWrfCKnlgFkq0qPThraZ7L0y/4Z x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f7f8da45-e445-42ef-7e13-08d5e2887417 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:MW2PR00MB0378; x-ms-traffictypediagnostic: MW2PR00MB0378: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027023009)(20171027022009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(93006095)(93001095)(3231280)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MW2PR00MB0378; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0378; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(346002)(376002)(366004)(199004)(189003)(13464003)(7696005)(186003)(99286004)(53546011)(2900100001)(26005)(6506007)(8676002)(6916009)(76176011)(6246003)(9686003)(55016002)(5660300001)(6436002)(2171002)(4326008)(446003)(486006)(74316002)(7736002)(5250100002)(102836004)(476003)(11346002)(316002)(6306002)(86362001)(81166006)(22452003)(86612001)(305945005)(478600001)(8990500004)(33656002)(25786009)(2906002)(66066001)(72206003)(81156014)(10090500001)(8936002)(68736007)(14454004)(10290500003)(53936002)(3846002)(106356001)(229853002)(6116002)(105586002)(97736004)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0378; H:MW2PR00MB0298.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) x-microsoft-antispam-message-info: qetFb31uIPfQ2XgP9g5nHZJ5ZLrqzXjc9s/XLsmMkcnAvzAncBwmzAvOe3jvWbtrcQfD7/1ib2HcnW1sqALTjR0i9D9a/hMzYi2ejt/atH56+ee/Fq+WkvDw5PiWhRPdCzajoUJq7FDRJX6CwMEQCEzieIDFghsXMWn3K4S8OtlCcuzi/fbBTnMc6tNalhLJ3UQoc5oRtyEenlkJGWfl0Fg1e248g5x/QINlQs2j6QJc3AFoKbpWDOCnj44+azTBb/+d248zOf1A6Q94tot++DDB0paS5reFQ+7cdbEywCTlNaJnSqZ973B5urgzCog49Z2Xu39T9NbHRz8dtrqa8biIAtqAWG70rLAhP/RZ2JM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7f8da45-e445-42ef-7e13-08d5e2887417 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 15:03:23.3078 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0378 Archived-At: Subject: Re: [OAUTH-WG] PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 15:03:28 -0000 [See my reply to Ludwig, since the thread forked] -----Original Message----- From: Benjamin Kaduk =20 Sent: Wednesday, July 4, 2018 2:47 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] PoP Key Distribution On Tue, Jul 03, 2018 at 08:10:52PM +0000, Mike Jones wrote: >=20 > I believe that the ACE "profile" parameter is typically unnecessary=20 > and not in the spirit of normal OAuth. Configuration information=20 > between OAuth participants is typically configured out of band and/or=20 > retrieved from the AS Discovery document (per the newly minted RFC=20 > 8414). There's no need to=20 > dynamically exchange a profile identifier when this is essentially=20 > always known in advance. We should not include "profile". For that=20 > matter, ACE For what it's worth, this part of "the spirit of normal OAuth" is something= that leaves me with lingering unease. While I do not dispute that this so= rt of configuration information is usually known out of band or via discove= ry, we ought to be considering the potential consequences when the parties = do not actually agree on what configuration should be in use. An explicit = indicator makes for an easy-to-analyze "fail quickly" scenario, whereas lea= ving things implicit is much harder to reason about. And yes, this case of= easier analysis is at the cost of complexity elsewhere, so there is a trad= eoff. -Ben From nobody Thu Jul 5 08:04:50 2018 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 7847B130E7A for ; Thu, 5 Jul 2018 08:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_DKIMWL_WL_HIGH=-0.01] 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 TPaIGcvrgBsK for ; Thu, 5 Jul 2018 08:04:46 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640134.outbound.protection.outlook.com [40.107.64.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE590130DED for ; Thu, 5 Jul 2018 08:04:40 -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=NFVVSHKOFE1qvRfsqcgSbiX6PCO5pvXvHq1GqlPGogQ=; b=M6uIfc/5xXZ73NrK5+COd+ynJ5HwvLRBjuK4LJOB5uWKOZy4+zGRZuzAbTBVdEP+rVArB2/f6rktZRnHgVO1xplg3wokKVcO3k14C7UIELnquW9qqJJeLzxJzbkitf8z0O5zP8EHmtYcTdWnEOD5NWaVgzW22QeWEyhrxT61Erc= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0428.namprd00.prod.outlook.com (52.132.149.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.967.0; Thu, 5 Jul 2018 15:04:35 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::9c24:5ebc:cf1a:dc37]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::9c24:5ebc:cf1a:dc37%6]) with mapi id 15.20.0971.000; Thu, 5 Jul 2018 15:04:35 +0000 From: Mike Jones To: Ludwig Seitz , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] PoP Key Distribution Thread-Index: AdQTBj47ZlOcOW2pSHSpIBiWadk6FgAXco4AAENT58A= Date: Thu, 5 Jul 2018 15:04:35 +0000 Message-ID: References: <58eac9f9-21a6-aa6d-ac28-6fce70cfa08e@ri.se> In-Reply-To: <58eac9f9-21a6-aa6d-ac28-6fce70cfa08e@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0428; 6:KZ6RNvpMdid6aLrofjX4sceKhMh2gfGZUkpi4YMUM9oSbtFTPhC1vb7zzGHrBZRBmvKmjKMQIGOZ94XK7ALbEUVsbSllg7+TH3mflaVCtECnou2lmaiBEOHlQgLprgJUAKWqy3Z9vHTWvTaAQfDZSHXG2X/DACrt6BR6W1OIKGBGmQTM+PfYF8kHswFrBKDMg8jz7MVOJQPzxIkOaorzzuav0qberJOpg55llq/i+37+aCcEf6GNzks+1Io3zxhjKtThmEvW+WTNy4LLGtYyUP+Td954zHZzxBkeSNtp3NhVHiQFSM/rGpukTZUEyJLKSJOYrc65EuLIIzPz7x/28CFXb4h/lgsEi/QEaaDkFRlEIN1535ZyWTWejvIvmr3aoAw+rjYSEsDaLFP8AOINvrj+BrQ75YlXQRXL/7tigdAeXrRq7TDvzGAzqft4zyVS7KzejmA6Dq3AvmMU8xKQwg==; 5:LByWBUaduLl4H+AWByA6KKppmjYe9Jy3k1DLa7FDRtqFXcTfo/rYVaF+d1WMoiYHBqxtFtjSgSyXwAz1kpGPZ/5X+pboCto6wcZgqis24ggnVTwTm3XOznMtS3kDxgvRHVZb+4xPA13iU93F7/N3LbtC7WJKziWwf/TCozNV3WE=; 7:F2nAVuYVfdvTWWVFBBObpnGU7NajCDyGBNMesASygxIoE0sKerrEAdCwPMj02Q3+PJzBCq6+7lr71Ynrq29d0JFYZu20MU6iAHSXtygaGYCXun2C/51Vk9MU/cB2sBupzHnmgzSQeJmneVH7w1Crn8Cu3sbxciFCmJFE+6P11R6AYn5Y8Kbfh9nko/CPyU6YDzRLHrryz0FRLJlVZmMRBHbOlb37DjWTLPSCAF6X4hWCl9VYxI0OiwkIr+ZZVcUG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e9dd39b7-9036-4b88-ca47-08d5e2889f22 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:MW2PR00MB0428; x-ms-traffictypediagnostic: MW2PR00MB0428: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3002001)(10201501046)(3231280)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MW2PR00MB0428; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0428; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(396003)(39860400002)(376002)(366004)(53754006)(199004)(189003)(13464003)(186003)(99286004)(5660300001)(53546011)(2900100001)(53936002)(7696005)(26005)(8676002)(76176011)(6506007)(6246003)(6436002)(6306002)(55016002)(9686003)(5250100002)(486006)(11346002)(74316002)(446003)(102836004)(7736002)(476003)(110136005)(316002)(86362001)(8936002)(81166006)(256004)(305945005)(14444005)(2501003)(81156014)(33656002)(8990500004)(478600001)(25786009)(86612001)(966005)(14454004)(22452003)(10090500001)(68736007)(2906002)(72206003)(10290500003)(6116002)(3846002)(229853002)(97736004)(105586002)(106356001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0428; H:MW2PR00MB0298.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) x-microsoft-antispam-message-info: IOj9yqRBB9I82dZsL1BOgtWbgsVsu9nV9mAlbsrbzcI/G7DPjwuyz5pauS8BgMYqi0PWQ7/FdRHmsvZ22jC/k91Jnrb9vWIzUybm8XPdQ6xc7K1yg+Q6V+8n6Q3VJEZE29Do9X3Ejv2wyl/Hjm5RzbGS6xd9pZkPjF2Vvj9yobhdynMXcxcyFacmcVSiaXdXTbF1xX7gpIsQhzwJqp+yqwWvR1vT5oNTcIXf7xEbNOurgwiusWAGhLMylSYHIymU+UmyGT9ps7P65/kH891Ljy9YGwSTnD5D3gBAREF0iq0PGuYa6hUnWPHOOP5UQOibKBjkOQIsEOMsWyeCNM3UE6jGy1jTO20khrTwYIcb1mE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e9dd39b7-9036-4b88-ca47-08d5e2889f22 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 15:04:35.5319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0428 Archived-At: Subject: Re: [OAUTH-WG] PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 15:04:49 -0000 I'm fine putting some bandwidth into finishing OAuth PoP Key Distribution -= particularly now that OAuth AS Metadata is finally done. I know that Hann= es is willing to do so as well. -- Mike -----Original Message----- From: OAuth On Behalf Of Ludwig Seitz Sent: Tuesday, July 3, 2018 11:56 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] PoP Key Distribution On 2018-07-03 21:46, Hannes Tschofenig wrote: > Hi all, >=20 .... > Where should the parameters needed for PoP key distribution should be=20 > defined? Currently, they are defined in two places -- in > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in=20 > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03.=20 > In particular, the audience and the token_type parameters are defined=20 > in both specs. >=20 > IMHO it appears that OAuth would be the best place to define the=20 > HTTP-based parameters. ACE could define the IoT-based protocols, such=20 > as CoAP, MQTT, and alike. Of course, this is subject for discussion,=20 > particularly if there is no interest in doing so in the OAuth working=20 > group. >=20 I fully agree that OAuth would be the best place. I've only drawn some of t= hese parameters into draft-ietf-ace-oauth-authz because the work on draft-i= etf-oauth-pop-key-distribution seemed to have been discontinued (it expired= August 2017). That said, I'd hate to introduce a normative dependency into draft-ietf-ace= -oauth-authz on a document that will not move forward or only move very slo= wly. What are the prospects of going forward quickly with draft-ietf-oauth-= pop-key-distribution? > There is also a misalignment in terms of the content..=20 > draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter,=20 > which does not exist in the draft-ietf-ace-oauth-authz document. The=20 > draft-ietf-ace-oauth-authz document does, however, have a profile=20 > parameter, which does not exist in=20 > draft-ietf-oauth-pop-key-distribution. Some alignment is therefore=20 > needed. In the meanwhile the work on OAuth meta has been finalized and It seems indeed that 'alg' and 'profile' parameters have some overlap, alth= ough 'alg' seemed a bit more narrow to me (which is why I created 'profile'= ). If we could extend the definition of 'alg' a bit, I'd be OK to remove '= profile' from the ACE draft (provided the OAuth draft moves forward in a ti= mely manner). /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jul 9 07:42:06 2018 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 96E5B131008 for ; Mon, 9 Jul 2018 07:41:57 -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 XzWajoNZ_FCs for ; Mon, 9 Jul 2018 07:41:55 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 36456130FFC for ; Mon, 9 Jul 2018 07:41:55 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id q12-v6so11866186ual.2 for ; Mon, 09 Jul 2018 07:41:55 -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=3ow5RlOr2Uf6KBAr8Q5ohtOqNnB2ie6FXaLKmCtJWCo=; b=ZrAPAWmgX0/B8A+yXhLwYFxrTu/hHgm9QABsvkWwVHGdTE5SUSvyX0JRHHTV12FCEf NZ3JBagKOKyQuTPtXBJRk1Qic+0br459CSOzzB5L5mgGmeXGsDStvRtIpFHVqP4gwmdi jNuSJ5YG1ti2nS8pRyUzgZG/baeqBHU5UFrbDhU0OR/aRMRRtfV/IdaSGleCyaraFQeh r1bUHIlI/M4fjxhQSsdDxCTaUQCX1m3YzUhwCoQDeseUstaYH8rChDFEtcG1+K9bTFpH O1bBTjnvTV4iP3qi+zG9mt/XEJZCzsMjA6DtvRWOP012u3EmtJv3jAtjPObePw+dtrGU vmIA== 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=3ow5RlOr2Uf6KBAr8Q5ohtOqNnB2ie6FXaLKmCtJWCo=; b=NQ5cQVcpRfE1cqAzgdTuNGjwBMla1yxSHfQHBlkhOUESjhIikufoyeafckNjncG8NI DGOeilokfY5q0mTE7GZhez8rZaj6mq3VKAjXXO6BlZw4YLenoHUzRaxrTnzj/4b1ZHn2 5pj8E0dX0/IKrS0dD7NSCaNPl2OlJQ8kKfPJCY1KK12lH/4rc6aPaDNcbaZbcCddBKAt IHOxHbQSw2KZ8y1r1b7uKUok99xOZNWk3GuxvGNACcKZV7/e28K1jEuVN7oXId8yJbog Rq6ZPKVX+2gCUrjtTTUBtubYsWFmVeK4Gk0QhnWOp8KCd3FpSgLnvz3Mzcd6XNYKZ5/j ko4A== X-Gm-Message-State: APt69E0fWFytT5tskkB/CoPhAhtqWVAQcvz0hK+Ip8mmUnvSARH7yiJ1 dAlpSTt0WCyxstMGGNbAwMS2CmjIt0zgzOwjlzavQRNw X-Google-Smtp-Source: AAOMgpcukXMfQD+pRxJ03Aok1XDiFOvLL3wImqONETUZmzytW9b4OwC03yFPsXsY4gQmW71m9E398Z6xLfdD3Nb9ujU= X-Received: by 2002:ab0:4853:: with SMTP id c19-v6mr12932779uad.157.1531147313853; Mon, 09 Jul 2018 07:41:53 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Mon, 9 Jul 2018 10:42:23 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000bdb6c30570920314" Archived-At: Subject: [OAUTH-WG] OAuth WG draft agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 14:42:03 -0000 --000000000000bdb6c30570920314 Content-Type: text/plain; charset="UTF-8" The following is a draft agenda for next week. Please, let us know if you have any comments. Regards, Rifaat & Hannes Web Authorization Protocol Meeting ---------------------------------- ** 15:50-17:20 *Tuesday *Afternoon session II ** (90 minutes) * Chairs Update (15 min) * OAuth 2.0 Incremental Authorization (30 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ * Reciprocal OAuth (30 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ * OAuth 2.0 Token Binding (15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ ** 9:30-11:00 *Thursday *Morning session I ** (90 min) * PoP Tokens (60 min) OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 * Distributed OAuth (30 min) https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ --000000000000bdb6c30570920314 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The following is a dra= ft agenda for next week.
Ple= ase, let us know if you have any comments.

Regards,
=C2=A0Rif= aat & Hannes

<= /font>

Web Authorization Protocol Meeting
----------------------------------

** 15:50-17:20= =C2=A0 =C2=A0Tuesday Afternoon session II ** (90 minutes)
=
* Chairs Update (15 min)

* OAuth 2.= 0 Incremental Authorization (30 min)

* Reciprocal OAuth (30 min)

* OAuth= 2.0 Token Binding (15 min)



** 9:30-11:00=C2=A0 =C2=A0 =C2=A0Thursday Morni= ng session I ** (90 min)

* PoP Tokens (60 min)
=C2=A0 OAuth 2.0 Proof-of-Possession: Authorization Server to Client= Key Distribution

=C2=A0 OAut= h 2.0 Proof-of-Possession (PoP) Security Architecture

* Distributed OAuth (30 min)

--000000000000bdb6c30570920314-- From nobody Mon Jul 9 12:33:53 2018 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 EA528130E35 for ; Mon, 9 Jul 2018 12:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 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, HTML_OBFUSCATE_20_30=1.999, 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 4TjyY8nPRbyt for ; Mon, 9 Jul 2018 12:33:51 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 0BAD812785F for ; Mon, 9 Jul 2018 12:33:51 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id s21-v6so14368765pfm.6 for ; Mon, 09 Jul 2018 12:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version; bh=hxj1gdZsYkuvhEZnLWYFhxa+WDDi8RjIVuavxiNwgSQ=; b=YGorQVk/b68NRLI9o3WRqhndj8h+8KKc03Uo3wDo7HqQvzUoOy+XelhHV6pIIX/brR olx3V9eQd4hEMorcBA70qrcNEpqlbwSWZw3jrOMq4KimBC1HS6NXVTp1fWRrZsahXGg/ Tlg4eD5HBQ9QVS0OlO/0ZOLcbgJDOO9Sk3sWTCpzCDRS+S+uP0OeDT6xvSIDDYORRQA+ KunoVmcyTvDM9/f+bAshLLkq+diTp0hzIwCPWENwjkUKiE65aHQGq7hxdWoiib9jo7z+ gOPQIaw6zpm0x/JL/KouG0kdXyrZ0j9YSqkQ8QUH2yUxKDcJp8uYKdZ6s3//iJ7JLObv /o3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version; bh=hxj1gdZsYkuvhEZnLWYFhxa+WDDi8RjIVuavxiNwgSQ=; b=If7pXGC4zjnhqTwdoV7J6sKPPLiAl3QcvJRZ0ePFXS7Vm/VQqT6SuDZ2kePG9BME5B AwRYmgoAPDbmYSiV19r6iEdyC6Avklp19s5BFF74rTlhtfO2fSBClY6VDoftlpmzO5FP TQejJc+jg90LFX+O39SDx63NlGDI1kF94cCYV4jvj9luQ/TrpOjqEVyBYmVJBOI8v4sv ilZgdJ0a5VUhHnobdlxzBHwKWW79yibX5M/JW9L4MW3DSJ1GPoFK3H5OKavP5apFjiUH yyVM4xj7zQjHuXLxqDCFF6K/yRDxoH9oVDX4r344ZLhClGh0zws6OiWHaUF0QZ43H99O pwtA== X-Gm-Message-State: APt69E1KglAjmCH3E8MV4wMMYjiTqdsUro8t7eprKa+LNCgWvgpt6/EA cSpCdpEBI3ZXY51Dv4EGIvmH5Wjq X-Google-Smtp-Source: AAOMgpclmPUr4/4FyojkHnsgdHc7wt0+2WjGQRWPCGIuByHfI4NIBKkVzFrGdsPieaDj4dpLs9v1bQ== X-Received: by 2002:a63:e0b:: with SMTP id d11-v6mr20229112pgl.134.1531164829934; Mon, 09 Jul 2018 12:33:49 -0700 (PDT) Received: from [2404:160:8020:45a7:d0a5:bf0d:100::] ([2404:160:8020:45a7:a93e:441a:92d1:3d96]) by smtp.gmail.com with ESMTPSA id m9-v6sm22407375pge.25.2018.07.09.12.33.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 12:33:48 -0700 (PDT) Date: Tue, 10 Jul 2018 03:33:46 +0800 From: Eysz 7Words To: Oauth Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5b43b89a_6b8b4567_e2" Archived-At: Subject: [OAUTH-WG] eysz@ietf.org X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 19:33:52 -0000 --5b43b89a_6b8b4567_e2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline kofutzueexoycyij --5b43b89a_6b8b4567_e2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline


kofutzueexoycyi<= /span>j
--5b43b89a_6b8b4567_e2-- From nobody Mon Jul 9 21:49:05 2018 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 E3417130EF7 for ; Mon, 9 Jul 2018 21:49:02 -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 UKr217pegWNV for ; Mon, 9 Jul 2018 21:49:01 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0: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 E802C130DDB for ; Mon, 9 Jul 2018 21:49:00 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id r1-v6so1730313pgp.11 for ; Mon, 09 Jul 2018 21:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CJBBy5qE/XFtoYbZde+33Xe9WtT3C4K/jakMAmiDdN0=; b=FkBNBIeqpnZzggnlbROEoS7D8UUZqgmJCjqZqKD15zeJXCm2KtvKWH1QzPlt3Soslg O4PbZBZ+334a0jTeD+ifM/F2zw1RIGxGpE3Q4Wf0V+W3d/r0zoIjTvBgbRMnIj35j+J5 pOCv/+GBVcQ3019WLNoX4b3YOpMVHaSkVST2xHrcNvSFzRqbe2j2snP0pRvTzISrUjyQ nLSiIXu+7TVl+JIXczeg7CZbE0F12kWa6RAe3k3kxnuQr2KKP1rYkQI5jdEUPsp67ml4 H8arCi+2DMw90QFvuG036NIRKsmGCcE9d2jEB1qxQR9DpWI/Rc4mcTkfRdKEX83iwhx2 lusA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CJBBy5qE/XFtoYbZde+33Xe9WtT3C4K/jakMAmiDdN0=; b=qDyNnAWuDDQZ0KW6gZkQNSCVxId32CqHyyNrbCOQBsl/lopRL0xqSQXPBV8Viqtojt tFNe24bPI3rnDll1xt7egwm7uwHFSvPgqc6ZnWxfTDzDN7m5KTBuFUfpRYNDgfe5uvcF SuepPB3cv1+HS1YWgdaXpdaTdEWZwDypadXPwfyvV74HkiW19G9BeI1ADBoyxdFxcXVi Hh4Vja1LMlFkGGJm1u49S14999Rci545pq67zStgkCTwifFS+l6V15T6Y7hStD1Nmr65 dnVZiIcmlNFuMgiMncF1WhGWZSMEQeFHEMJ5iPxfCuUXGkHJuwmJ0QwFnIMXY1+oD5D6 MLug== X-Gm-Message-State: APt69E1/sfU0rdj6TMCmscekmAvAwiOimgMHoTWpYYo9dZtI9x1cq8fI NzcQutQ8PAPKCmLJum8hCJ0gFAMf+oV+OYD6iU0= X-Google-Smtp-Source: AAOMgpcXejETjb69MtzTxMzj3cu77/EOmN9NBYD4xc7Dpnysg0riVXd/1Hh5+2YzvDa2AmAClFaUb0mj73KQTjTReD0= X-Received: by 2002:a62:bd03:: with SMTP id a3-v6mr23893417pff.138.1531198140353; Mon, 09 Jul 2018 21:49:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:8901:0:0:0:0 with HTTP; Mon, 9 Jul 2018 21:48:39 -0700 (PDT) In-Reply-To: References: From: Dick Hardt Date: Mon, 9 Jul 2018 21:48:39 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="0000000000003c92c005709dd968" Archived-At: Subject: Re: [OAUTH-WG] OAuth WG draft agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 04:49:03 -0000 --0000000000003c92c005709dd968 Content-Type: text/plain; charset="UTF-8" Besides being the oddness that session I happens after session II ... looks ok! On Mon, Jul 9, 2018 at 7:42 AM, Rifaat Shekh-Yusef wrote: > The following is a draft agenda for next week. > Please, let us know if you have any comments. > > Regards, > Rifaat & Hannes > > > Web Authorization Protocol Meeting > ---------------------------------- > > ** 15:50-17:20 *Tuesday *Afternoon session II ** (90 minutes) > > * Chairs Update (15 min) > > * OAuth 2.0 Incremental Authorization (30 min) > https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ > > * Reciprocal OAuth (30 min) > https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ > > * OAuth 2.0 Token Binding (15 min) > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ > > > > > ** 9:30-11:00 *Thursday *Morning session I ** (90 min) > > * PoP Tokens (60 min) > OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key > Distribution > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 > > OAuth 2.0 Proof-of-Possession (PoP) Security Architecture > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 > > * Distributed OAuth (30 min) > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0000000000003c92c005709dd968 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Besides being the oddn= ess that session I happens after session II ... looks ok!


On Mon,= Jul 9, 2018 at 7:42 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
The following is a draft agenda for next w= eek.
Please, let us know if = you have any comments.

Regards,<= /div>
=C2=A0Rifaat & Hannes



<= br>
** 9:30-11:00=C2=A0 =C2=A0 =C2=A0Thursday Morning sess= ion I ** (90 min)

* PoP Tokens (60 min)
= =C2=A0 OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Di= stribution

<= /div>
=C2=A0 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture<= /div>

* Distrib= uted OAuth (30 min)


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


--0000000000003c92c005709dd968-- From nobody Mon Jul 9 22:44:35 2018 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 AE8F2130E0E for ; Mon, 9 Jul 2018 22:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 dgflaYALdZ7t for ; Mon, 9 Jul 2018 22:44:31 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 43A44129C6B for ; Mon, 9 Jul 2018 22:44:31 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id k25-v6so4282549uao.11 for ; Mon, 09 Jul 2018 22:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2kTjvDCtT1VV+NwYrxmTY9OYlwJmedFNQD+QOMm/xPY=; b=QQ1B+JsA25hu5mQBR3vdU7OP9u7NQnL30pV7Ddr9EKnQeU4Y9ayfr4+zDzNOJ8IC2m RhcVcjKU+q92YNVKOdEja0FpKFH5uicIHpLX1wGqrBSor/KUNkSwde4w2xEjnOU1bDEz 03CAm8sVDyjra3Ofi53AVeLWk+/GzJM1v5zmiLOPhvEC4VpH6KwwGwHgWr/ViNY6vgJP 5bXC7V4EZs+lgQLnPF+4chE9ovEgDZxhJuTIpNRUsPLlg1astDuaDw7vm1BeRtXEfr8m O59oBfWVB6XBb0d//IO2QDDsZ5av8pkNgFsKCbXq+juM/tPuKuPHjVKLxlpA1+QajIW3 5YFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2kTjvDCtT1VV+NwYrxmTY9OYlwJmedFNQD+QOMm/xPY=; b=mGaUfwBtNpGVaIC+EIS+otCL2a9AEo4tK9WKX+M04sot5jNI+5V9tTHce4uw9VJ5GL AjS8JNMje1I/9snznDB6gzlaGvPelR5Q8lwd1qTt0kHzPCupI9fU7P0UkvdeL8sG/Sr3 2HWaJ6yRGtYhQmR5GzZYqz/aQPlWZha1rFJDgn1R2CVvKemIzJN12q2A4Yqv4ld3W98f ZlUc/3Ya8F6wvfhYhtZejvb//nITMdM/0HhJTaCM/EvmaTSrdjOxUGX18sH5HPVrXUKc CPKOlH4/mOMcalDF+K9nuh+/ie2NEEJTXej/I95a4E0CaTKdNi8p99R4Cxxb5MFxdYjw 2Hrg== X-Gm-Message-State: APt69E0txg01zRtDqSu0OF9jgEAZNm1BatlxYMmkcwHoGqXidrDxI9sN PCMgMn4HRqpASZFwlXz8uXZyTTeCIrdKbE5gHgORHQ== X-Google-Smtp-Source: AAOMgpe+dtN7rFNHPbjutxpX5snrAwuc1TxLwk5UobLCx6J84dcenPLT5ssK6W1a+ThVaE0Z/rIzV6xWmBsJTMjqbJI= X-Received: by 2002:ab0:130a:: with SMTP id g10-v6mr13537080uae.175.1531201469676; Mon, 09 Jul 2018 22:44:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:6383:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 22:44:09 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Mon, 9 Jul 2018 22:44:09 -0700 Message-ID: To: Dick Hardt Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="000000000000ae6b3105709e9fe2" Archived-At: Subject: Re: [OAUTH-WG] OAuth WG draft agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 05:44:34 -0000 --000000000000ae6b3105709e9fe2 Content-Type: text/plain; charset="UTF-8" Is it OK to me to present Incremental OAuth remotely? I'm not able to travel for this IETF, but am registered as a remote participant. I think 20min might be enough to cover that draft timing wise, unless there is a lot of discussion. Looks good overall, and I appreciate being scheduled in the afternoon session on account of the timezone difference. On Mon, Jul 9, 2018 at 9:48 PM, Dick Hardt wrote: > Besides being the oddness that session I happens after session II ... > looks ok! > > > On Mon, Jul 9, 2018 at 7:42 AM, Rifaat Shekh-Yusef > wrote: > >> The following is a draft agenda for next week. >> Please, let us know if you have any comments. >> >> Regards, >> Rifaat & Hannes >> >> >> Web Authorization Protocol Meeting >> ---------------------------------- >> >> ** 15:50-17:20 *Tuesday *Afternoon session II ** (90 minutes) >> >> * Chairs Update (15 min) >> >> * OAuth 2.0 Incremental Authorization (30 min) >> https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ >> >> * Reciprocal OAuth (30 min) >> https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ >> >> * OAuth 2.0 Token Binding (15 min) >> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ >> >> >> >> >> ** 9:30-11:00 *Thursday *Morning session I ** (90 min) >> >> * PoP Tokens (60 min) >> OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key >> Distribution >> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 >> >> OAuth 2.0 Proof-of-Possession (PoP) Security Architecture >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 >> >> * Distributed OAuth (30 min) >> https://datatracker..ietf.org/doc/draft-hardt-oauth-distributed/ >> >> >> >> _______________________________________________ >> 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 > > --000000000000ae6b3105709e9fe2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is it OK to me to present Incremental OAuth remotely? I= 9;m not able to travel for this IETF, but am registered as a remote partici= pant.=C2=A0 I think 20min might be enough to cover that draft timing wise, = unless there is a lot of discussion.

Looks good overall,= and I appreciate being scheduled in the afternoon session on account of th= e timezone difference.





On Mon, Jul 9, 2018 at 9:48 PM, Dick Hardt &= lt;dick.hardt@gma= il.com> wrote:
Besides being the oddness that ses= sion I happens after session II ... looks ok!


On= Mon, Jul 9, 2018 at 7:42 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.co= m> wrote:
The following= is a draft agenda for next week.
Please, let us know if you have any comments.

Regards,
= =C2=A0Rifaat & Hannes


<= div>
Web Authoriza= tion Protocol Meeting
----------------------------------

** 15:50-17:20=C2=A0 =C2=A0Tuesday Afternoon s= ession II ** (90 minutes)

* Chairs Update (15 min)=

* OAuth 2.0 Incremental Authorization (30 min)

* R= eciprocal OAuth (30 min)

<= /div>
* OAuth 2.0 Token Binding (15 min)



** 9:30-= 11:00=C2=A0 =C2=A0 =C2=A0Thursday Morning session I ** (90 min)

* PoP Tokens (60 min)
=C2=A0 OAuth 2.0 Proof= -of-Possession: Authorization Server to Client Key Distribution

=C2=A0 OAut= h 2.0 Proof-of-Possession (PoP) Security Architecture


_______________________________________________
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


--000000000000ae6b3105709e9fe2-- From nobody Tue Jul 10 04:44:07 2018 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 C9207130F79 for ; Tue, 10 Jul 2018 04:44:05 -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 LsADTktWOfWI for ; Tue, 10 Jul 2018 04:44:03 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 4DA58130E6F for ; Tue, 10 Jul 2018 04:44:03 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id x24-v6so13740485ual.10 for ; Tue, 10 Jul 2018 04:44:03 -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=ZQNJAM2xL9O6bVq/qYKjeX2hs/26TkaI0oUBX/o90tg=; b=PdyjJPv+vhdFXbCmzCmFWUlpmZcKJrgacBdJyETnFlK8pyJm2CTinhircA6Zfwg963 gUQobVyRhXSTO8OPg8WvVEK/az4Lda+qVPXDpSiSHoow6ikGT5HZRu6cPcwXphnqsB/0 +FFgRWm5anEi3DKhyndOWUgKAEGTmJqtaBeKYd9n+VrFr0pveU+DAuWcIFEiCN8tB6Ya dT1r4lcr2y0/EAojCFyGc4azkfszxlnfA6lFQoyawGMYv2RFVUeFb/QEJcbSPHADHF+V 3UOo6Gb+HbfjbIEgLveuNJFqBomUXqqedi2kF/gbLTsp04rvhC/2qS/ayfk5LBoZsaM0 8bcQ== 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=ZQNJAM2xL9O6bVq/qYKjeX2hs/26TkaI0oUBX/o90tg=; b=q6zO2+DPzMUWLers5JevitLhJIYtAgAkVwBG3Ox63XUQm3Kv+NfXpKeDr4ziUVJtY+ aCXUXuCnvovt8J/RRPLW62IYoaq8wUN5UnlqwAJijzIns3gwJ8cHxoas8Dc65Oryn8S2 b/8nalyloAk8Bb8nazk6Z+M/JnEl2Z1TgQ9oN5S8YzsRPdLEL9dq7ALz62sp9iSoWTQd d5pGyqGYakl5MaDcXt1VS3ZhLIIVWtdAoQ3SqYVedsFpI8Jmt0gLFRjvisHnXXjATGys W1HB9y826AhrMlda2dKjfWXmVSjhMXYOCZt8dRO/DF22pu+iu6hMHlhlHriR7oz5xEs3 foaw== X-Gm-Message-State: APt69E0hTSbuiufBdFrwTP7D8KFzT6ThmzE9sBr/WIdcARk1KKHbFy5r iKCR3jkzn/39P2zbek5Vb4WOmZYA78IR5CMDZkM= X-Google-Smtp-Source: AAOMgpcQGs9Z8q9XJN42ehSLRI1AgAnMLstLD88KF7nvZYTWiap7zZzZnMjFspmaI5y8gWQeUNIKCt4AmjlJytCm9SA= X-Received: by 2002:ab0:51e7:: with SMTP id h36-v6mr15269837uaa.70.1531223042350; Tue, 10 Jul 2018 04:44:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 10 Jul 2018 07:44:33 -0400 Message-ID: To: Dick Hardt Cc: oauth Content-Type: multipart/alternative; boundary="00000000000082e3a30570a3a515" Archived-At: Subject: Re: [OAUTH-WG] OAuth WG draft agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 11:44:06 -0000 --00000000000082e3a30570a3a515 Content-Type: text/plain; charset="UTF-8" :) These are the day's sessions. On Tue, Jul 10, 2018 at 12:49 AM Dick Hardt wrote: > Besides being the oddness that session I happens after session II ... > looks ok! > > > On Mon, Jul 9, 2018 at 7:42 AM, Rifaat Shekh-Yusef > wrote: > >> The following is a draft agenda for next week. >> Please, let us know if you have any comments. >> >> Regards, >> Rifaat & Hannes >> >> >> Web Authorization Protocol Meeting >> ---------------------------------- >> >> ** 15:50-17:20 *Tuesday *Afternoon session II ** (90 minutes) >> >> * Chairs Update (15 min) >> >> * OAuth 2.0 Incremental Authorization (30 min) >> https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ >> >> * Reciprocal OAuth (30 min) >> https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ >> >> * OAuth 2.0 Token Binding (15 min) >> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ >> >> >> >> >> ** 9:30-11:00 *Thursday *Morning session I ** (90 min) >> >> * PoP Tokens (60 min) >> OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key >> Distribution >> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 >> >> OAuth 2.0 Proof-of-Possession (PoP) Security Architecture >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 >> >> * Distributed OAuth (30 min) >> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --00000000000082e3a30570a3a515 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
:)
These are the day's sessions.
<= /div>
On Tue, Jul 10, 2018 a= t 12:49 AM Dick Hardt <dick.hard= t@gmail.com> wrote:
Besides being the oddness that= session I happens after session II ... looks ok!


On Mon, Jul 9, = 2018 at 7:42 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
The following is a draft agenda for next week.
Please, let us know if you have a= ny comments.

Regards,
= =C2=A0Rifaat & Hannes
<= div>

W= eb Authorization Protocol Meeting
-------------------------------= ---

** 15:50-17:20=C2=A0 =C2=A0Tuesday Afte= rnoon session II ** (90 minutes)

* Chairs Update (= 15 min)

* OAuth 2.0 Incremental Authorization (30 = min)

* Reci= procal OAuth (30 min)

* O= Auth 2.0 Token Binding (15 min)
<= br>


** 9:30-11:00=C2=A0 =C2=A0 =C2= =A0Thursday Morning session I ** (90 min)

*= PoP Tokens (60 min)
=C2=A0 OAuth 2.0 Proof-of-Possession: Author= ization Server to Client Key Distribution

=C2=A0 OAuth 2.0 Proof-of-Possession (PoP) S= ecurity Architecture

* Distributed OAuth (30 min)

<= /div>

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


--00000000000082e3a30570a3a515-- From nobody Tue Jul 10 04:47:42 2018 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 6D20C130F7B for ; Tue, 10 Jul 2018 04:47:40 -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 TOkveBnbVe4Q for ; Tue, 10 Jul 2018 04:47:38 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 33D40130E6F for ; Tue, 10 Jul 2018 04:47:38 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id t14-v6so13751041uao.8 for ; Tue, 10 Jul 2018 04:47:38 -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=GIN7KlGxzcaA+uSqWIV44yH9vE40Yje2bDGpL5a4bWA=; b=DW6ZFyY1584fBgzMtvdYKrX2bj1t7QPfP9mxsIN5nUY7LWxzEspZzaVKkPv425m70J nLPniif1OCXLbIleD7a+WIikAfnC4bkoIq5K8ViMNws+r1i8WAPFjNOc5aXsOfen9nV2 cNLY+rkMNWJmuF5fmJ6D03LKnyQAxIe0CAYrjzpvxkiNUxwbGY9X9Lqg/+XClkkuOYJz t+CODb2pWTufqUp5R9pHlpnVUU1u6X5XbIQi5ItP4FkoD3484immxVCwda/FtxFjyghM G/FBzxi+nc+i17obTDmXWtBuFvI4eNu8N7+CFQj13M0nQCCYUQfHGW3jEZzA5vk8XANg q0YQ== 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=GIN7KlGxzcaA+uSqWIV44yH9vE40Yje2bDGpL5a4bWA=; b=Hyxhh2U9G9q0Vy/Y5BRdL+tH3vf7q8C7Cn4OXCRcE8btu0EW4M+0znoKtjpB+pWuE1 nEEfrip69qnXwk22REFtLK6ZM2FFclt63/gX5aE7s5oMut30HKBqcXaAJZYjkyGPSttL cr5KfLZTdKykFRFu9hCXSa4XoE+3TLFmPbZiKEtwmbP9fxjg4qh1Kx4GYHviY5Muyrb/ fcU8uPtHUPCN2vx1/PQ2VX/4si7Fd60zRRJq7QMfjLy0JE6dbIU4zLFHgMrMcU/SDVEK mSE7s/ia2Nb1131GG9xwJ8FYn3mDe6VKq0eawJJK1nndrLJWgnwXaBg3eCWYu39w3E0g yz3g== X-Gm-Message-State: APt69E0PbEoQNuK/LQDjfOmixRzbzA9GQ/Ap4J2+9AN7UId+/G4w5kkr VBmJKGOowNtETFqnu2erFd1rQTBHYyU6fvxPybA= X-Google-Smtp-Source: AAOMgpfMzvdfJcA1YGljHMMhO01LmwoMj51HvMV/Lv/KbJqUqTA0Dyihko76B4HC0yANZP1PgNDa+MTIkIA+WlaA/Wo= X-Received: by 2002:a9f:2633:: with SMTP id 48-v6mr14991931uag.182.1531223257300; Tue, 10 Jul 2018 04:47:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 10 Jul 2018 07:48:08 -0400 Message-ID: To: William Denniss Cc: Dick Hardt , oauth Content-Type: multipart/alternative; boundary="00000000000052c29e0570a3b22e" Archived-At: Subject: Re: [OAUTH-WG] OAuth WG draft agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 11:47:41 -0000 --00000000000052c29e0570a3b22e Content-Type: text/plain; charset="UTF-8" You absolutely can present remotely. Let us know if you need any help with the setup. Regards, Rifaat On Tue, Jul 10, 2018 at 1:44 AM William Denniss wrote: > Is it OK to me to present Incremental OAuth remotely? I'm not able to > travel for this IETF, but am registered as a remote participant. I think > 20min might be enough to cover that draft timing wise, unless there is a > lot of discussion. > > Looks good overall, and I appreciate being scheduled in the afternoon > session on account of the timezone difference. > > > > > > On Mon, Jul 9, 2018 at 9:48 PM, Dick Hardt wrote: > >> Besides being the oddness that session I happens after session II ... >> looks ok! >> >> >> On Mon, Jul 9, 2018 at 7:42 AM, Rifaat Shekh-Yusef > > wrote: >> >>> The following is a draft agenda for next week. >>> Please, let us know if you have any comments. >>> >>> Regards, >>> Rifaat & Hannes >>> >>> >>> Web Authorization Protocol Meeting >>> ---------------------------------- >>> >>> ** 15:50-17:20 *Tuesday *Afternoon session II ** (90 minutes) >>> >>> * Chairs Update (15 min) >>> >>> * OAuth 2.0 Incremental Authorization (30 min) >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ >>> >>> * Reciprocal OAuth (30 min) >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ >>> >>> * OAuth 2.0 Token Binding (15 min) >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ >>> >>> >>> >>> >>> ** 9:30-11:00 *Thursday *Morning session I ** (90 min) >>> >>> * PoP Tokens (60 min) >>> OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key >>> Distribution >>> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 >>> >>> OAuth 2.0 Proof-of-Possession (PoP) Security Architecture >>> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 >>> >>> * Distributed OAuth (30 min) >>> https://datatracker..ietf.org/doc/draft-hardt-oauth-distributed/ >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > --00000000000052c29e0570a3b22e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You absolutely can present remotely.
Let us know if yo= u need any help with the setup.

Regards,
=C2=A0Rifaat



=
On Tue, Jul 10, 2018 = at 1:44 AM William Denniss <wdenn= iss@google.com> wrote:
Is it OK to me to present Incremental OAuth remotely? I'm n= ot able to travel for this IETF, but am registered as a remote participant.= =C2=A0 I think 20min might be enough to cover that draft timing wise, unles= s there is a lot of discussion.

Looks good overall, and = I appreciate being scheduled in the afternoon session on account of the tim= ezone difference.




On Mon, Jul 9, 2018 at 9:48 PM, Dick Hardt <dick.hardt@gmail.co= m> wrote:
= Besides being the oddness that session = I happens after session II ... looks ok!


On Mon, Jul 9, 201= 8 at 7:42 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>= wrote:
The following is a draft agenda for next w= eek.
Please, let us know if = you have any comments.

Regards,<= /div>
=C2=A0Rifaat & Hannes


Web Authorization Protocol Meeting
--------= --------------------------

** 15:50-17:20=C2=A0 = =C2=A0Tuesday Afternoon session II ** (90 minutes)

* Chairs Update (15 min)

* OAuth 2.0 Incre= mental Authorization (30 min)
<= div>
* Reciprocal OAuth (30 min)
=C2=A0 https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/

* OAuth 2.0 Token Binding (15 min)
=C2=A0 <= a href=3D"https://datatracker..ietf.org/doc/draft-ietf-oauth-token-binding/= " target=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-oauth-token= -binding/



** 9:3= 0-11:00=C2=A0 =C2=A0 =C2=A0Thursday Morning session I ** (90 min)

* PoP Tokens (60 min)
=C2=A0 OAuth 2.0 Pro= of-of-Possession: Authorization Server to Client Key Distribution
=C2=A0 https://tools.ietf.org/html/draft-ietf-oaut= h-pop-key-distribution-03

=C2=A0 OAuth 2.0 Pro= of-of-Possession (PoP) Security Architecture

* Distributed OAuth (30 min)


_______________________________________________
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


--00000000000052c29e0570a3b22e-- From nobody Tue Jul 10 05:00:49 2018 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 E44AC13111B for ; Tue, 10 Jul 2018 05:00:46 -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 4o5aGXNMqamQ for ; Tue, 10 Jul 2018 05:00:40 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 EEF06130FA5 for ; Tue, 10 Jul 2018 05:00:39 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id y8-v6so13774474uan.3 for ; Tue, 10 Jul 2018 05:00: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; bh=oymZF7fg8/JnvFzxumqz+VI2H2o0j40+4Ow04IYKkDw=; b=YcOaEhU9BWsON7bRTn6uLSKOX6+xLJfRT+PD7+Q/2tKtH/RAJo/fIMUzCv0pvOIlj3 KtSo84oWv5iH9g4LrmKIw+MFaON0dw5iWfzrTPHFYae1eYR/boGCTV54KjqoAGkZOw6p UVnk+IvVNH5Lrb+jU59Qc1hlDL41D2V7R3C4Kz1rDwUcYrLkLTBiYha8l8lUyAqTZj36 MmAaNt3aODHn7N7nUaahQnOKetseOStxL78qDS07oEBelPd62g2gDd8lqkMHO6JYaGRr PNLciaRn7U8eqo+iIz2DPKGWGSam1+SX/vyCPg0OWEx/IbG6jfHewSZWDRRLKdhI1wzm Wu4A== 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=oymZF7fg8/JnvFzxumqz+VI2H2o0j40+4Ow04IYKkDw=; b=FbyLRMQ0Aw25veoS4Rc1ttSzjMetsFgbBYS8AtyIA0Npb6aoleo2wSHuJuP0kTUewR ADaTEShaBkAj/zSrYmBAOOa1fK4qC8sLCjRFlZEzCs4pgo0jicZJTRckPgQXCCmQQZWr ZjFrSu1Ccis4U5BTlmxfl91QjIR6VyEAgHAFAdlBfWn8RJzWW7Yz5kks4hs2s/3NAtEw dlZzVNmyRD9EU5fSe5/zuFWhAhXtfUzVaNB01npZOLQy+Kjazb7DO8QAL8wkqnXCkKgB B2yLeMbGAl37X1PEemdXDIhfBQcTTYG/OdU3OBtlEhvfCgOrTK4kjBE8KHl75wAkrBCc f65w== X-Gm-Message-State: APt69E1niaBi5sm0l98LhlfUVV6PfqQcnjzYGwhlzNxv6unq2UBzMZyb aPefTbB32Vl5c9YGi2UAnmn+h1Zd5suJegMoGXXlCvqO X-Google-Smtp-Source: AAOMgpezOX/Mq85v0LwpWN3V0bS4BSrRt3KCmKuSieSOwHqlnq49GkqlhMnenang5M935IrqBO0zH9Icp6uOu14tj04= X-Received: by 2002:a9f:2633:: with SMTP id 48-v6mr15017980uag.182.1531224038903; Tue, 10 Jul 2018 05:00:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 10 Jul 2018 08:01:09 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000e913d60570a3e0b4" Archived-At: Subject: Re: [OAUTH-WG] OAuth WG draft agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 12:00:48 -0000 --000000000000e913d60570a3e0b4 Content-Type: text/plain; charset="UTF-8" Here is a link to our final agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-oauth-00 Regards, Rifaat On Mon, Jul 9, 2018 at 10:42 AM Rifaat Shekh-Yusef wrote: > The following is a draft agenda for next week. > Please, let us know if you have any comments. > > Regards, > Rifaat & Hannes > > > Web Authorization Protocol Meeting > ---------------------------------- > > ** 15:50-17:20 *Tuesday *Afternoon session II ** (90 minutes) > > * Chairs Update (15 min) > > * OAuth 2.0 Incremental Authorization (30 min) > https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ > > * Reciprocal OAuth (30 min) > https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ > > * OAuth 2.0 Token Binding (15 min) > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ > > > > ** 9:30-11:00 *Thursday *Morning session I ** (90 min) > > * PoP Tokens (60 min) > OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key > Distribution > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 > > OAuth 2.0 Proof-of-Possession (PoP) Security Architecture > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08 > > * Distributed OAuth (30 min) > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ > > --000000000000e913d60570a3e0b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Regards,
=C2=A0Rifaat


On Mon, Jul 9, 2018 at 10= :42 AM Rifaat Shekh-Yusef <rifa= at.ietf@gmail.com> wrote:
The following is a draft= agenda for next week.
Pleas= e, let us know if you have any comments.

=C2=A0Rifaa= t & Hannes


Web Authorization Protocol Meeting
---= -------------------------------

** 15:50-17:20=C2= =A0 =C2=A0Tuesday Afternoon session II ** (90 minutes)
* Chairs Update (15 min)

* OAuth 2.0 I= ncremental Authorization (30 min)

* PoP Tokens (60 min)
=C2=A0 OAuth = 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution

=C2=A0 OAuth = 2.0 Proof-of-Possession (PoP) Security Architecture

* Distributed OAuth (30 min)

--000000000000e913d60570a3e0b4-- From nobody Tue Jul 10 05:50:54 2018 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 50386130E5F for ; Tue, 10 Jul 2018 05:50:48 -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 NcyCQLtEvk8w for ; Tue, 10 Jul 2018 05:50:45 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 11F9F12F18C for ; Tue, 10 Jul 2018 05:50:31 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id z8-v6so9625431qto.9 for ; Tue, 10 Jul 2018 05:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version; bh=O3xXJxmuCxAO8s4VRvDySJyDfDLwi2B/X1CINX6ypTA=; b=KytCIIW1/WnpynEJdkqnG5429Omrh44KsdsCQh60ZboHoL2as0naHy6PUybbp+Xk3B V0+I+JaIqyxJynfI2GhiBl5+RkLL9BkNsJI4ZNWRLapjOzYvVpkQMcnKVBtR+idXn4S0 dBJ/sfr8HXkc+Po8CGAny/NyLIexPoWHM09dVR3LFu+jh2k0WF/by4/CgP7pNjcjwB6M MnaYiHkUDioey+r9h5bPC98Id+LgbHGcInu4kSwQ8TWANGyk13zRGG9yz9Ch1n5h2ICg M/0WsmUhVv16Yq3ynTV6Rnz6h8gGKhotFNoIUxBIklMbpTBE6JYDJaykGVYj0DK71lSf jf7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version; bh=O3xXJxmuCxAO8s4VRvDySJyDfDLwi2B/X1CINX6ypTA=; b=nj+DwCoNxMVzwZgH3b6BU2nA7/dbjUBPdnb62jdvLpPUgq2xOaJDcA75YMraGr+Kc4 N2o8KNGmeL89khUANYV3+BvYe0siZaVpvqGmyntV9Rm6dfZvtmV/S80aQ5nGFkyz+unb AKOyfFbovZn6YDswStxTa2KMo4OhXTnnhokebxVK2A0wsuazLo+V1Pa5BkIJTOJ5EZXe MxgaOQrh1d6P2gAWvkWdgix95FmZ310xp2UO5lq7YeQ4rkWypomxVNr54lWKvUZcu/nr J4O7wJlvPdEuNIrZZNUB4vKdLKv+G3bTTwKw0yjySjFiPkjo1vPr0SmJVAwR+Cfwzk/R hncg== X-Gm-Message-State: APt69E3V3yn+D4fvgDL9qBGzdkVjOyDb0VzWeyrF78vLIdsGeNN9mYhX nJASf1PTZlV61GlyWDkERqhy1Mit X-Google-Smtp-Source: AAOMgpdGyKPG1Ru7QiA5ut6SL4ZPFOpfSMky5jASbZLqUQXG1Z6qTBdawE8I+olWxouAwgVYtx5lfQ== X-Received: by 2002:a0c:8a1b:: with SMTP id 27-v6mr21490791qvt.159.1531227029606; Tue, 10 Jul 2018 05:50:29 -0700 (PDT) Received: from mail.outlook.com ([40.76.67.137]) by smtp.gmail.com with ESMTPSA id y128-v6sm11852523qkc.1.2018.07.10.05.50.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 05:50:28 -0700 (PDT) Date: Tue, 10 Jul 2018 12:49:57 +0000 (UTC) From: Eysz 7Words To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9452_1236375668.1531226997911" X-Mailer: Outlook for iOS and Android Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 12:50:49 -0000 ------=_Part_9452_1236375668.1531226997911 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit eysz@ietf.org Dapatkan Outlook for iOS ------=_Part_9452_1236375668.1531226997911 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Yaron, Dick, Mike,

 

Please confirm that any and all appropriate IPR disc= losures required for full conformance with the provisions of BCP 78 and BCP= 79 have already been filed for draft-ietf-oauth-jwt-bcp-03.

 

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_VI1PR0801MB2112BAF58658C304BFC06199FA5C0VI1PR0801MB2112_-- From nobody Tue Jul 17 06:36:48 2018 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 CEF8B130DC7 for ; Tue, 17 Jul 2018 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 Q0TQBqFn6lEb for ; Tue, 17 Jul 2018 06:36:43 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640090.outbound.protection.outlook.com [40.107.64.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F45D12F1A2 for ; Tue, 17 Jul 2018 06:36:43 -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=eb10sOxaUXDVl1qGF2aTokmLvBaxvKFnKNC8SIXeaKw=; b=GayepzybtYBjHdNMzltkLFq2YbriA1ep2Hn58V77W7cRdhlVzEHMiv8didcMIjmKipgo6O46I9/08UZ6pv8CM5TR7L5hD4OD6s/kGYu212kBvDwV/x+2TH+R9Ofla2X0iAtC4HbxJUIIcRqWcLB3c5YNQ9rRSEcBwxtbS/CXBYQ= Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0444.namprd00.prod.outlook.com (52.132.149.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1010.0; Tue, 17 Jul 2018 13:36:40 +0000 Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::40d0:7f75:41be:2672]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::40d0:7f75:41be:2672%4]) with mapi id 15.20.1011.000; Tue, 17 Jul 2018 13:36:40 +0000 From: Mike Jones To: Hannes Tschofenig , Yaron Sheffer , Dick Hardt , "dick@amazon.com" CC: "oauth@ietf.org" Thread-Topic: IPR confirmation for draft-ietf-oauth-jwt-bcp-03 Thread-Index: AdQd0wXe7c+RbgwkQ+G4SSH6Y364KwAAB4CQ Date: Tue, 17 Jul 2018 13:36:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1232:144:b0cd:50e:127c:eea] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0444; 6:iJrA2jh4zwRHZBBsYCelgwabm5ZQJUnvvBYEW0AWvTWnPUpThPt0WZd/KVvPOdioUeUtyGuZH+hyEZL1/W7G5ptvkodkLNnM3KS4xnp+nbuM+y4CyKbeeGoTKn4aeG/yYuGjG6lyVvNJdOhC+qKbYM1hcnnzMmzfbieopsNetHZs9O5mtSw3NqyD4w4IcWCPZls1rInkP3k7qjaXVNsKg7gyM+EDMgS9eMB9qP8zgYAiGkSdco3zpuyG/qfE4lOFL892saG4CCvujrDXrKEPhapzMCTd2Hv9wbKfZvTtPMD0QudoxkPc3g5q2hija6RMgXvxdDkU9ETB67eKC5jB76lyVCJEZxtQ+sX0lZP4UqkMciMFO85TrnEzFThvrBx/curbN5bSa0//1PYcvbmR+flt7Zik2bcu7GV5cVilWYQNbnbO4FG+DCzFWQhIgMT8g5jGzpaaa92YOATCHmDzbA==; 5:qtFNX/zJwyp3HezGvWTnJakKwiH3q7Lh+YoymVALaToR72hpuSSon8f9p2FB12HRCvFA6a9qE8z4THsMjRh+2nHvWbOehErjcTBaRUGQui29h0J5ehNH3TkH++SXpdzZSGfRHhmBiKpYRxzz5ZtQR82EBpJjJGKWspJzrU/iwlI=; 7:BnkGc+5pM7M4/Ohgr00UNi6yM7/FT2weg7zkpPPxQWuDYYlfX4mVYhlEjg9j2LLpnPY09ZLm/erGimY1OVgB1T9MvPfGP0oxlsRmkSOAucR3p9bU925s1NQ6SRTjHLIro9TlAC/SmbSBpjsrJZAZ+RHgzxA+Idl9CH/9ajZyejd40VtlBT7sUVRqLDaW9nEgCLoon+5VTO0dM5tsWv7hlo32sR2+/MwxD6VhSQUjZNGLFPgkRYS4AUkOFwo6kEtL x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a662d143-b77b-4b93-a844-08d5ebea53bf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:MW2PR00MB0444; x-ms-traffictypediagnostic: MW2PR00MB0444: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(89211679590171)(223705240517415)(85827821059158)(21748063052155)(47284530071512); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3231311)(944501410)(52105095)(2018427008)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:MW2PR00MB0444; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0444; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(376002)(136003)(39860400002)(40434004)(199004)(189003)(68736007)(76176011)(86612001)(86362001)(81166006)(446003)(10290500003)(99286004)(2501003)(97736004)(4326008)(39060400002)(19609705001)(7696005)(5024004)(256004)(8936002)(5250100002)(72206003)(14444005)(186003)(53936002)(5660300001)(316002)(22452003)(7736002)(14454004)(2906002)(478600001)(11346002)(8990500004)(6246003)(790700001)(476003)(110136005)(33656002)(46003)(74316002)(106356001)(105586002)(6116002)(486006)(53546011)(6506007)(25786009)(10090500001)(102836004)(8676002)(55016002)(6436002)(6306002)(9686003)(54896002)(229853002)(2900100001)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0444; H:MW2PR00MB0298.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) x-microsoft-antispam-message-info: dLGXJYMR1nqZTbCMw5DpPhG0pxIWP3WEHL6GqpmA1SFLY6RuxEhvW6hBQn04eN2qfHiEbmy5YU45tXT5LrnPp5m6RWTQwfGd7wGbZSVQTKLZ8DjW3cxI47Au216e1PfbZK0IK1w92gLXbVOD55WA6RTyLCsLs1LOZmNYHfYsXmmlOiM0OD/RmeNZOVLtefcMSGO9WmN6LtyCiRGT3BQKbx2yQJ7IvI5nSC9j0N8/flRO1lv7vivb/EWssA0XUCKiVipCRjOfxUe9O9w276kVoPmVIk/TuDv3T2lt+cTUXwv1U5ctjxNkyG5FVK8ZGxnVNiPSqOvy9B3X/2cNuDz7aDvZbnCFT2UWmzg0TmCPkB0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR00MB02988B8E17B8F7C1C00C538BF55C0MW2PR00MB0298namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a662d143-b77b-4b93-a844-08d5ebea53bf X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2018 13:36:40.1926 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0444 Archived-At: Subject: Re: [OAUTH-WG] IPR confirmation for draft-ietf-oauth-jwt-bcp-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 13:36:46 -0000 --_000_MW2PR00MB02988B8E17B8F7C1C00C538BF55C0MW2PR00MB0298namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR that pertains to the JWT BCP document. -- Mike From: Hannes Tschofenig Sent: Tuesday, July 17, 2018 9:36 AM To: Yaron Sheffer ; Dick Hardt ; dick@amazon.com; Mike Jones Cc: oauth@ietf.org Subject: IPR confirmation for draft-ietf-oauth-jwt-bcp-03 Hi Yaron, Dick, Mike, Please confirm that any and all appropriate IPR disclosures required for fu= ll conformance with the provisions of BCP 78 and BCP 79 have already been f= iled for draft-ietf-oauth-jwt-bcp-03. 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_MW2PR00MB02988B8E17B8F7C1C00C538BF55C0MW2PR00MB0298namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of any = IPR that pertains to the JWT BCP document.

 

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

 

From: Hannes Tschofenig <Hannes.Tschofenig= @arm.com>
Sent: Tuesday, July 17, 2018 9:36 AM
To: Yaron Sheffer <yaronf.ietf@gmail.com>; Dick Hardt <dick= .hardt@gmail.com>; dick@amazon.com; Mike Jones <Michael.Jones@microso= ft.com>
Cc: oauth@ietf.org
Subject: IPR confirmation for draft-ietf-oauth-jwt-bcp-03=

 

Hi Yaron, Dick, Mike,

 

Please confirm that any and all= appropriate IPR disclosures required for full conformance with the provisi= ons of BCP 78 and BCP 79 have already been filed for draft-ietf-oauth-jwt-b= cp-03.

 

Ciao

Hannes

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immedia= tely and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

--_000_MW2PR00MB02988B8E17B8F7C1C00C538BF55C0MW2PR00MB0298namp_-- From nobody Tue Jul 17 06:37:13 2018 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 7C68B130F3C for ; Tue, 17 Jul 2018 06:37:04 -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 W0Mj9EzxBDwg for ; Tue, 17 Jul 2018 06:37:00 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 47DE6130F53 for ; Tue, 17 Jul 2018 06:37:00 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id j8-v6so520894pff.6 for ; Tue, 17 Jul 2018 06:37:00 -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=QIaaHqgjLo0jJtR9TTWq0U6H7CKZCQgDRBZmuRtRe5I=; b=gwtS6/TdcIZ95wQE2u/1Cn+g3JV+aplggj2unh7e0ajYoIxUjpbwR49lmv1NXz9azJ SlBwzHdR72psLD7UL4hUI7BnpnPqz+ft738Xm+hN5ju0B+l1v6Uq06o+U7Dwr24y+VO7 9pPvSi8EQUpoWZx98oFC38E2KQ8/Dlt5uZEiqxT7lPfsyKiXCcnvFYSoCZwZ5bCaxsiD cQmU8fWaJvTtZsn85k0Ws0AYE/hI3ovMy63kszAwNsW5Zbik7i7McIO/qarp0n5+84bW 6ae5qvuK6ItJvWqeUGuyCYQgyGPI1PyAPo2zoycKGK1kHa8pjVDFU7qt8WBCNvORJmB/ eNfg== 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=QIaaHqgjLo0jJtR9TTWq0U6H7CKZCQgDRBZmuRtRe5I=; b=KuLebMoqBp4ia2MgO3B4u/aKxOHyhPAXU2w2rMnTNbLFYz+no2QDGoDi1Dp7YoAUva x3ZudeWE4FfrJpL1DC3QjRTOErZ/IW4bVOAUx9Kyrwgj0JAnGm9r9fSEPn826+iNQtQC OERAVYqajhz+Mt5nurRMjEUHVtrslhI1q9Ro6hLrC8tSPRby0FF4bQHLZb+4I/beuzub aSDYNa36CC7pn+0WcACvjCcCdBUzCizZTLpUmiYq8Ex3bAeFCeb5Q2JgzXATqkcrkEka nB13u4HblBIzUzhTniu5lMvdOOPO+Q0uXQ39BN9R9tNieJ9u/v6X4I+AjhFHRmUIYkEs 0jQA== X-Gm-Message-State: AOUpUlEtRLXcTJdbz5lwRBoy4HsXc4N8hZPQ70jzlI7sTSLvPEZF5DFX jmaKbakjNfNjVlJ7z+RSW23MsrfO63+PRxJx6nE= X-Google-Smtp-Source: AAOMgpeBjlAh2BovETgKgpaKvabh/43yxPwR0IPmZxv5/9SjM64rP9LqMwyGjOkMrBoLskxqGdLY1Jws9JER50Cj0T8= X-Received: by 2002:a65:62ce:: with SMTP id m14-v6mr1618196pgv.407.1531834619669; Tue, 17 Jul 2018 06:36:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 17 Jul 2018 09:36:47 -0400 Message-ID: To: Hannes Tschofenig Cc: Mike Jones , Yaron Sheffer , "dick@amazon.com" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005c35c30571320aa4" Archived-At: Subject: Re: [OAUTH-WG] IPR confirmation for draft-ietf-oauth-jwt-bcp-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 13:37:11 -0000 --0000000000005c35c30571320aa4 Content-Type: text/plain; charset="UTF-8" Confirmed, thanks. On Tue, Jul 17, 2018 at 9:35 AM Hannes Tschofenig wrote: > Hi Yaron, Dick, Mike, > > > > Please confirm that any and all appropriate IPR disclosures required for > full conformance with the provisions of BCP 78 and BCP 79 have already been > filed for draft-ietf-oauth-jwt-bcp-03. > > > > Ciao > > Hannes > 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 the > information in any medium. Thank you. > --0000000000005c35c30571320aa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Confirmed, thanks.


On Tue, Jul 17, 2018 at 9:35 AM Hannes Tschofenig <= ;Hannes.Tschofenig@arm.com= > wrote:

Hi Yaron, Dick, Mike,

=C2=A0

Please confirm that any and all appropriate IPR disc= losures required for full conformance with the provisions of BCP 78 and BCP= 79 have already been filed for draft-ietf-oauth-jwt-bcp-03.<= /p>

=C2=A0

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.
--0000000000005c35c30571320aa4-- From nobody Tue Jul 17 06:58:47 2018 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 DE9F6130FB5 for ; Tue, 17 Jul 2018 06:58:36 -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 vFnzdPsQPCDj for ; Tue, 17 Jul 2018 06:58:35 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 3F974130F35 for ; Tue, 17 Jul 2018 06:58:35 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id z19-v6so1054638ioh.4 for ; Tue, 17 Jul 2018 06:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ad59e3vcLRG3Zg6i1AXqVVya85Q7hV5ogBwHdJL+ZE8=; b=CRfStZ5tzs1/SfGejbVZ7NsZq/exJMGb2fOzXVjNviOmUGdaR+r2RWSBrHHwGoR+3O F8zz611H/F+5tlWM/iH9vZfn1ohHrxE0sYjbPbvD+pAuVjHxFnOkfmtTk46Lshkubt21 KeRVXPNqyi24oupGHgv0dReIJ3Dgl8P+nOhpe77ivSYuGxjsfNzTkVVidiJ8SNCg+v6h uwEh6u0XvGUPTJE3I6jRQx65NY3rRAv/KhlDEjR/ZdH2E+uRxZQU5WE1LKQLR0yxjeNS JPEXGLlnhosWT93kz4/bR+QaSfxsLB9FZ+fzgybBLqnOclRsihiYUpEs6DTTwzO3wImn /bwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ad59e3vcLRG3Zg6i1AXqVVya85Q7hV5ogBwHdJL+ZE8=; b=IzL6TnbxOz/ahZrq54L+xXCgXVKH33WJ65JJ6ntuYp9hCpU+Tdg/p0Z5HIDo1uUAhD WHp1yf1LadrLsgf5NCodn/wd2+zJL5u81TNbdle4GsbpxgbnafheAx280IAQSoF0Iybo ccRt5Vc5//eM8HVY7CGJH++Clqn/FNg/qP8pVmoVlR617z0GVWW5tyyHlPDVODfr0Nw6 B3k3qlnvMUkXA2ls5I2OYuzXEqNBIFmLnQrgRDu4dpo7F1se6miWyFHRQOthGvMTOTin Cuz21ZnRg9J7rUc3BR+uHF842ob3EFdjN7WP606PaHplYvx0t7QodOfsqdm0l3f+5Epl Gpqg== X-Gm-Message-State: AOUpUlHeCSRRPUVHY7eiY2RxTqW+QPf8Gi8+IZ0Wouj8HyBYxFEJD15C o+aUREizba3y0AuNlM3mWkIQlCMt X-Google-Smtp-Source: AA+uWPxfyVnNVpu6/idqh5FmX11zAT0kP6j1xpHJbP/usq4djIn3DHG0dF4xyURrOqWJUeGhrkSAQg== X-Received: by 2002:a6b:5b16:: with SMTP id v22-v6mr1431027ioh.265.1531835914403; Tue, 17 Jul 2018 06:58:34 -0700 (PDT) Received: from [172.20.5.95] ([207.115.103.227]) by smtp.gmail.com with ESMTPSA id j137-v6sm655800ita.27.2018.07.17.06.58.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 06:58:33 -0700 (PDT) To: Hannes Tschofenig , Dick Hardt , "dick@amazon.com" , Mike Jones Cc: "oauth@ietf.org" References: From: Yaron Sheffer Message-ID: Date: Tue, 17 Jul 2018 09:58:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] IPR confirmation for draft-ietf-oauth-jwt-bcp-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 13:58:45 -0000 Confirmed. Yaron On 17/07/18 09:35, Hannes Tschofenig wrote: > Hi Yaron, Dick, Mike, > > Please confirm that any and all appropriate IPR disclosures required for > full conformance with the provisions of BCP 78 and BCP 79 have already > been filed for draft-ietf-oauth-jwt-bcp-03. > > Ciao > > Hannes > > 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 > the information in any medium. Thank you. From nobody Tue Jul 17 07:06:32 2018 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 13A01130DFD for ; Tue, 17 Jul 2018 07:06: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, 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 7H0EjU9vGE7x for ; Tue, 17 Jul 2018 07:06:29 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 2F64C129385 for ; Tue, 17 Jul 2018 07:06:29 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 16-v6so1959293itl.5 for ; Tue, 17 Jul 2018 07:06: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=wu0qu5X8CakyvFIp603Y3inm4cF1k2L2ErzAfs/0LOY=; b=T5LNHAPgbi09/jKclV/HZc6IkqWMuGfsxuVbdzRBSSJnZC/f/mPUssTHCjOIV7tWkl aJHGiHn77l4MhZHWXATt6liGmfZC1q6G0iNU4BuamkJAG+oBZ7+0QTQySKOJkgZfm86Q 3nxwa3cxdlnFP0wau1EyWkJ4nJeSE8jIUkZrhClodjXZxrOH+sCx9C2D2sW8b/C4NvXR 1xUA41Rfq1LL0TRVG4Wb+fT8OI3s4arOVDsXtpDm7v81XOPqJ1SOzU2oATWhPmJo2py4 m7S6AYueB/rs6T1qKwlGq1JOy4vpjQz7Rl0+OxDooAfqU6Ix4OPDRDEu1YJj/mKyldHd AqHQ== 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=wu0qu5X8CakyvFIp603Y3inm4cF1k2L2ErzAfs/0LOY=; b=INvRJ7YLCx0FBUWcuhCLVobDGtvzHPbJrwfE/rm5EFiwlMC5LC04siQK/eNFUq/sE9 Bw/FTyaILZ472gBlfqcXphS9F8a9X658MP3/2z86UpJ72ZHo4Pql8MFvpxgOeXiYg8TU w5se3jI/cIDcwQ8IO9jQ+N+D/vaEv4gZKWNkO204oepqaRXJK9XEyN3iO7oBNhCG79jc OjdldUtH0AGR0z/0JRXE7voJPbem4mrlVtvs8R8UHqR+8n/6P5qktim36osILG7SSPB1 uYg5GefvwiDB4PiWewTSRcnsdY63V7MIIm/BFLH0O/5s3p3FK35np7vJ3Ijf3E/rn8es DaAA== X-Gm-Message-State: AOUpUlHZ4sd4kc4BQlPOMQ3xMhehh23jS4D0OykrtG+nWCrwpYPkS7Xi dRZetK+YOfEdq1NUu1tmQNhIzVwSq3GeuFEh8suL7pbPrzs= X-Google-Smtp-Source: AAOMgpdKEKHVNYYXrG3Qpv6D6a+RCx78QhnFkGuZ08vrdvxTNAQAwGJt9NF8duPEbISa6kB4jl+JPrkOB3bmvNGLNio= X-Received: by 2002:a24:69c6:: with SMTP id e189-v6mr1596670itc.21.1531836388426; Tue, 17 Jul 2018 07:06:28 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Tue, 17 Jul 2018 10:07:02 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000c94916057132732e" Archived-At: Subject: [OAUTH-WG] MTLS - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 14:06:31 -0000 --000000000000c94916057132732e Content-Type: text/plain; charset="UTF-8" Authors, As part of the write-up for the OAuth MTLS document, we need an IPR disclosure from all of you. Are you aware of any IPR related to the following OAuth MTLS document? https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ Regards, --000000000000c94916057132732e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Authors,

As part of the writ= e-up for the OAuth MTLS document, we need an IPR disclosure from all of you= .

Are you aware of any IPR related to the followin= g OAuth MTLS document?

Regards,

--000000000000c94916057132732e-- From nobody Tue Jul 17 07:12:21 2018 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 81977127AC2 for ; Tue, 17 Jul 2018 07:12:19 -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 UqL_v7ioMADH for ; Tue, 17 Jul 2018 07:12:12 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 9471A130E19 for ; Tue, 17 Jul 2018 07:12:12 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id s9-v6so1678679wmh.3 for ; Tue, 17 Jul 2018 07:12:12 -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=pSyA2v623gutEKdthUfavViF+/e7OYPoXzs915bonmA=; b=EczPOqGEuDSB+FFlN/0jF1J2p0vB7wrDPiPfm2T46k9J+NIVrACenPOCPuo81JuCNq iDYUuAD8o2MY4qMwrnBAkgdWcPb+ENOvD2yfE1F6OndV7+PxscY/uwE/4Eijm9ROP6A/ Wg2rQlePS8uGMZMF0KsPSQYgv1q1Co5QKWX4ZMu4B/5ILEjB4xU5qblOAwbf6axmkp5z Gmy/FH0kosohrlJPLKajCz+DQVdKVgSsm9XMsvGynu3ZX10slWZkB2Ki5HNRuraiop9q Y1ffJzU+eAIsJJVfnRQPqUFnV8Q89OFffjz7NKlxNHbZADQUkKfkZ+k5GQvvc4da8Ka5 608A== 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=pSyA2v623gutEKdthUfavViF+/e7OYPoXzs915bonmA=; b=SK8KNXABN7V2EFfnIEiClWUICWzrvJZ0W9O/+QD2qQTMt90oEZzYQ/1Vp2UzTX5QB0 3iq/zE0WC8QZe02BVsFYzXcyZX1x0jPT9W4cRyExm/yy6UTgUPS3+qNAh4DlalcU/626 mDe3m++/jP5xxMH7S+g+UeoTRqaiSvzYmycoF6XqHSjgOft6HpDBAUFpl/uOMxZ09ppr u1S7zpk4XXwyNKe0FQnit3IowtydBJx8ZCI3vLibJ5XGf2EdAuSuBZM2ep7HxNZZIn/f hlnIQaZHSk7fRWU3EY6rhVETS5QkB9FfxlWMjpe8Qg5/3pRm0FK3SBj8ZOavMrlrMBPe soJw== X-Gm-Message-State: AOUpUlG8kOOEyz2caSRmyBHDC0GOjs4SsoCt0gbjPCoSPlz5N/sOoQZk fd5KAYvqjwELJc9O94fEUu3iEXmUTwb9r3WHFKU= X-Google-Smtp-Source: AAOMgpfrp4g/e3zcnsLql6NKUfkInI3FutCTjtAjsdac94JudpATGihEap5F/K45dlom+tL4l7h1k2xrcuBFVfEtBPg= X-Received: by 2002:a1c:3a8f:: with SMTP id h137-v6mr1593896wma.41.1531836730846; Tue, 17 Jul 2018 07:12:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Tue, 17 Jul 2018 23:11:58 +0900 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="00000000000032312d057132883e" Archived-At: Subject: Re: [OAUTH-WG] MTLS - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 14:12:19 -0000 --00000000000032312d057132883e Content-Type: text/plain; charset="UTF-8" Not that I am aware of. On Tue, Jul 17, 2018 at 11:06 PM Rifaat Shekh-Yusef wrote: > Authors, > > As part of the write-up for the OAuth MTLS document, we need an IPR > disclosure from all of you.. > > Are you aware of any IPR related to the following OAuth MTLS document? > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > > Regards, > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --00000000000032312d057132883e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not that I=C2=A0am aware of.=C2=A0

On Tue, Jul 17, 2018 at 11:06 PM Rifaat Shekh= -Yusef <rifaat.ietf@gmail.com> wrote:

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


--
Nat Sakimura = (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--00000000000032312d057132883e-- From nobody Tue Jul 17 07:22:58 2018 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 ACDEB130F1F for ; Tue, 17 Jul 2018 07:22:43 -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=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 spvhf0adF5zK for ; Tue, 17 Jul 2018 07:22:41 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 B2AFA130F6C for ; Tue, 17 Jul 2018 07:22:41 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id q20-v6so2144151ith.0 for ; Tue, 17 Jul 2018 07:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VWyEMH4uEEhfdhKAp9Wa8HnHZPtuCZ58d54bAirkeMM=; b=kTvrITWT+JCsQ5g/SieEtUb4zpRc5U4WX97x9k7FyTOSNJjFK663+gGUROXFnPHNQM /i9a/yFBcCYHKYVQeIPhi0lic8Hmi+VApzyquHvyVtGmgCf+Nuadah1xgO4PwiLYU93M wwzVJ7lR4hxkKmN5t4LRKdaHntWxiQiO0JO2o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VWyEMH4uEEhfdhKAp9Wa8HnHZPtuCZ58d54bAirkeMM=; b=flva5yce2JEttL7d9OMxEvSrjfPAEjkxisDjFby9yJiEwjvpBxUgO5vHYP3RV26EWF fSS7crTIaQydtsU4TcVLQhcOB+PGbcgMcCy3banesdMgjVWwKIP7USYdpQIg4W6J/4sq FXhIeSYi5/KH1NagXRO6HtlHtFt8Wkmu0npb3zZTqFrZq3MRHnyAtN87Tge2rKWlJ9Rf ftcXut9+x3aqvJCA/Wm0JWhuc7+cIrz5Mx7NphlzN6sjMJHce5VbcvivBubA1KLCKuI1 +69gdF77ZF0W1KimOgdIqxsePXzrhAULC4vVU5OOSVPsafilxCiHLeR2JQq88knNBZeT sj6Q== X-Gm-Message-State: AOUpUlEGKqgNeiDaoiGEs+3IAW0PXA+Uiz1rpVQnoU9CUGVlwtoL0pKV kFjpYe8TN/W6x+Z4YbrkL0Q5e5lEWCCxXDzq/kuLNtB+VVAkPfou1J2fQuSNAgNvR6UaOQ/6O5e Nzsfxp6wOOG1tXTZQ X-Google-Smtp-Source: AAOMgpeaAx+rOWAbU47g+T6Hc2IF5azoRKwJ81CAWju5rIwOVpDwN1byESn/V3bRnc0RAw4gblMg/QiZdLU4D+byShs= X-Received: by 2002:a24:19d5:: with SMTP id b204-v6mr1713991itb.25.1531837360913; Tue, 17 Jul 2018 07:22:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6d18:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 07:22:10 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 17 Jul 2018 08:22:10 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="000000000000c05d30057132ad58" Archived-At: Subject: Re: [OAUTH-WG] MTLS - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 14:22:54 -0000 --000000000000c05d30057132ad58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR that pertains to the OAuth MTLS document. On Tue, Jul 17, 2018 at 8:07 AM, Rifaat Shekh-Yusef wrote: > Authors, > > As part of the write-up for the OAuth MTLS document, we need an IPR > disclosure from all of you.. > > Are you aware of any IPR related to the following OAuth MTLS document? > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ > > Regards, > > > _______________________________________________ > 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._ --000000000000c05d30057132ad58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR that pertains to the OAuth MTLS docu= ment.

On= Tue, Jul 17, 2018 at 8:07 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.c= om> wrote:
Authors,

As part of the write-up for the OAu= th MTLS document, we need an IPR disclosure from all of you..
Are you aware of any IPR related to the following OAuth MTLS do= cument?

Regards,


_______________________________________________
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. --000000000000c05d30057132ad58-- From nobody Tue Jul 17 07:24:41 2018 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 CCC2412D7F8 for ; Tue, 17 Jul 2018 07:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 HZUy9etfh0Lq for ; Tue, 17 Jul 2018 07:24:33 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) (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 3CB60130E05 for ; Tue, 17 Jul 2018 07:24:33 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ffQty-0002Yo-VT; Tue, 17 Jul 2018 16:24:31 +0200 From: Torsten Lodderstedt Message-Id: <5D3C91EA-B760-4B6D-AECA-C1022AC0086D@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_004E4154-B5E8-44C9-B4B9-C0DB98552870"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 17 Jul 2018 16:24:28 +0200 In-Reply-To: Cc: oauth To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3445.9.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] MTLS - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 14:24:40 -0000 --Apple-Mail=_004E4154-B5E8-44C9-B4B9-C0DB98552870 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not aware of any IPR re the OAuth mTLS draft. > Am 17.07.2018 um 16:11 schrieb Nat Sakimura : >=20 > Not that I am aware of.=20 >=20 > On Tue, Jul 17, 2018 at 11:06 PM Rifaat Shekh-Yusef = wrote: > Authors, >=20 > As part of the write-up for the OAuth MTLS document, we need an IPR = disclosure from all of you.. >=20 > Are you aware of any IPR related to the following OAuth MTLS document? > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ >=20 > Regards, >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_004E4154-B5E8-44C9-B4B9-C0DB98552870 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNzE3MTQyNDI4WjAjBgkqhkiG9w0BCQQxFgQUPamjWVS6zEfY V1S9Xig+3wKarIEwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBABnlFHMbnCJFhNTMuoitq0OQZ9xnavbZxz4UHNVNATl8pkVGRMn5 DLbqCTbmoJUoI90dFaerqY3Czd7vvXbgxZUFcedCPXGdTIM8gTr8ijXWek5f78y4Kl/KS8UfQHFS jzJpF13fPALFOpwuFj0vCOjwa/tIGeZa31PNVOEwyYj3WRFX/uqxJXTgZ7MRY9bccbNgJ96Y+Ycp g+kBTt7zODqZGTbKsBIbObzxY/rHAPJ+Ay030AoWd5ViXJ4LdDWw1fiW4Ro/EiruiLhx3/xFtEoT IPVVUsHxxQsORGMywJadeP5jy6IAqlPbjxudwpkVi9A/ti71bfo9redfkT0uXF0AAAAAAAA= --Apple-Mail=_004E4154-B5E8-44C9-B4B9-C0DB98552870-- From nobody Tue Jul 17 07:37:23 2018 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 75F3C130F13 for ; Tue, 17 Jul 2018 07:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 Wj2tgFNgLlux for ; Tue, 17 Jul 2018 07:37:06 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10089.outbound.protection.outlook.com [40.107.1.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A27130FE6 for ; Tue, 17 Jul 2018 07:37:00 -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=V5703Emw33ctBGgWwuIDz52q6FD72UG+x14mJDUGF1A=; b=K9akD8vFcM57Z3nEA4tI3UHXjAOxWl49HMUGhrvdglrjuwyeVd3QxNls2356dbO3jew6CPq6VcglKxIFOfoY8ZvaVVJ5cgdd+bJUNd1h/5pZB3L0Go5TYEJVtnP4VLrLGEbwKiuM8kewEfK9E1PQHeP5t6HTEVqbDCtkLl2jehk= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1357.eurprd08.prod.outlook.com (10.167.198.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.17; Tue, 17 Jul 2018 14:36:57 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Tue, 17 Jul 2018 14:36:57 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" Thread-Topic: Shepherd Write-Up for draft-ietf-oauth-jwt-bcp-03 Thread-Index: AdQd243I2U3qEYbEQXmZVxaA14ytWw== Date: Tue, 17 Jul 2018 14:36:57 +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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1357; 7:sk2O30tc5Rvra6K1H3NRh7NNZU1oL9OMmTVu8gG+/TUOdU512wARJAh0pGFmNgIlidZNHFcy0TscsvudHTc78hgUm9nham39KPoUFWd54G+cMCgxKOXvUAUWffwzOBsp/F83gi1shgfWy3JPX9WZ1m4eN/S24tTCSFZaIGAxFMfUPmKrAlDbB8r3DT9SrXVfCf/9kxmAZjBfZhh5cPAEQXzFPQCeJ5+GEF6njObcWVWt4sQyc5iwUbs6lmtNFFSb x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 001bdc65-b14b-418a-ebb3-08d5ebf2bfce x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(48565401081)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1357; x-ms-traffictypediagnostic: VI1PR0801MB1357: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(223705240517415); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1357; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1357; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(346002)(366004)(39860400002)(376002)(40434004)(53754006)(189003)(199004)(33656002)(9686003)(5640700003)(97736004)(6306002)(476003)(6436002)(3846002)(6116002)(2501003)(72206003)(68736007)(14454004)(53936002)(55016002)(486006)(478600001)(305945005)(5660300001)(966005)(74316002)(7736002)(6916009)(66066001)(2900100001)(316002)(81156014)(1730700003)(8676002)(7696005)(25786009)(86362001)(81166006)(2906002)(186003)(99286004)(102836004)(2351001)(8936002)(105586002)(5250100002)(106356001)(26005)(6506007)(14444005)(256004)(5024004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1357; 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-microsoft-antispam-message-info: Y8do+vV/AIS9Je4kax52H/ujaTi39dEmrJgQZdIkWAQ4/Tzv7vR7pGkZ8U2va5+IFA5Pao1MjHZ4aSPgfITnHd0FT72I9QIyn5viFBtFokkvr6NrDiii6eOff0EXOuXn54uBU0yca7N4IqTrVuLGD0K9+eIpG0vzyp6/Fpvzd2yQ0r1mHVpaKxGN5P7uRAUo9wKW35WhExO2cnGWBO3QBjkjXz9atLY4AZ5DmVXWjvwBNJ/TjTll5S55mcRKQZ0OuKMWX1ufvS8Vulb+iBRvCsJ2Y2EPuUZAhbRxsjV9oHKbROLzonxwHPsjYAvI0XBpDlvZhNm94XZv+hHjt5p8OTCfRA/6LVeY1MPmq8QUaIc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 001bdc65-b14b-418a-ebb3-08d5ebf2bfce X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2018 14:36:57.4504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1357 Archived-At: Subject: [OAUTH-WG] Shepherd Write-Up for draft-ietf-oauth-jwt-bcp-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 14:37:22 -0000 Hi all, Here is the shepherd write-up for draft-ietf-oauth-jwt-bcp-03: https://data= tracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/shepherdwriteup/ Feedback appreciated. 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. From nobody Tue Jul 17 07:57:51 2018 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 23504130FA3 for ; Tue, 17 Jul 2018 07:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 3olJ95KRMBTC for ; Tue, 17 Jul 2018 07:57:26 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (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 64BED130F18 for ; Tue, 17 Jul 2018 07:57:19 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ffRPg-0000PZ-EA; Tue, 17 Jul 2018 16:57:16 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8AE21BD8-6EA5-4E77-9D27-00ACA47FC537"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 17 Jul 2018 16:57:13 +0200 In-Reply-To: <153021689405.18540.5214482725778765448@ietfa.amsl.com> Cc: oauth To: William Denniss References: <153021689405.18540.5214482725778765448@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 14:57:48 -0000 --Apple-Mail=_8AE21BD8-6EA5-4E77-9D27-00ACA47FC537 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi William,=20 please find below my review feedback. First of all, I think you managed to come up with the minimal extension = needed to address a very relevant use case. Thanks! - Section 5, last paragraph.=20 "the new refresh token issued in the Access Token Response (Section = 4.1.4 of ) SHOULD include authorization for the scopes in the previous = grant.=E2=80=9C Wouldn=E2=80=99t it be better to make that a MUST? Otherwise the client = must assume the AS decides to not include all previously granted scopes, = which in turn means the client must keep older grants (and hope the AS = dd not automatically revolve it). - Section 6.1.1 The section describes how a client should handle denial for incremental = authorizations. How is the AS supposed to handle it? =46rom the text one = could deduce the AS should not discard any pre-existing granted scopes. = Is that correct? Would it make sense to explicitly state that? kind regards, Torsten.=20 > Am 28.06.2018 um 22:14 schrieb internet-drafts@ietf.org: >=20 >=20 > 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. >=20 > Title : OAuth 2.0 Incremental Authorization > Author : William Denniss > Filename : draft-ietf-oauth-incremental-authz-00.txt > Pages : 8 > Date : 2018-06-28 >=20 > Abstract: > OAuth 2.0 authorization requests that include every scope the client > might ever need can result in over-scoped authorization and a sub- > optimal end-user consent experience. This specification enhances = the > OAuth 2.0 authorization protocol by adding incremental = authorization, > the ability to request specific authorization scopes as needed, when > they're needed, removing the requirement to request every possible > scope that might be needed upfront. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-00 > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-authz-0= 0 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8AE21BD8-6EA5-4E77-9D27-00ACA47FC537 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNzE3MTQ1NzE0WjAjBgkqhkiG9w0BCQQxFgQUw6KONitYf3LM 1HMOR2PEATQxUPAwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAKtate0Ft5S+FmsItB23Cfvru0tKPQlRdzor8JiFMaYJsvBOCmxP LSSSADW8o6R/uqEK74l0osrBnuI4xOMLaQrSyApfaU+0Jp4rnujXyhNvtDpFAiinyLVnd7VzyHez AowWQSSrAVmpKsQASezoRmNKXm6HcIqm3LCaN0QXelhxQ2L8RIKEqfHV/KNu7/YI0fW4AA31FfTM kEOElrpFZAT1BW8Vj3xoUBiwgN0qmQzhlRcmkiJMeFAwtmMV+3dfgjlO3VD7AePZOmD3QsmHyp4Y L0ARzEyUJu/vrbUB+DkYmcPPgv4gxFYfryUb9a4OdrmKqitE9weNAuQvD2u3KSgAAAAAAAA= --Apple-Mail=_8AE21BD8-6EA5-4E77-9D27-00ACA47FC537-- From nobody Tue Jul 17 08:22:56 2018 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 7B630130F73 for ; Tue, 17 Jul 2018 08:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YJxAMMDEHyXO for ; Tue, 17 Jul 2018 08:22:43 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.105]) (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 4838E126DBF for ; Tue, 17 Jul 2018 08:22:43 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ffRoG-0006XG-JI; Tue, 17 Jul 2018 17:22:40 +0200 From: Torsten Lodderstedt Message-Id: <52D0886F-C7B3-4F98-B1CE-70E8406656D5@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_AED7E529-88B6-4282-A411-357EB2AA4767"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 17 Jul 2018 17:22:37 +0200 In-Reply-To: <152719369843.5001.6781345939306593672@ietfa.amsl.com> Cc: oauth To: Dick Hardt References: <152719369843.5001.6781345939306593672@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 15:22:55 -0000 --Apple-Mail=_AED7E529-88B6-4282-A411-357EB2AA4767 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dick, I gave you draft a read and came up with the following questions: Section 2: How does Party A know it is supposed to conduct a reciprocal = OAuth flow if Party B does not indicate so in the authorization = response? Section 3 Party A is supposed to call the token endpoint of Party B using an = authorization code generated by Party A. How does Party B interpret this = code? Or does it just send this code back to Party A to obtain its = access token for A? Party B uses the access token issued to Party A in the first part of the = flow (ordinary OAuth code flow) to identify the respective user account = with Party B. Since the AS consumes its access token as an RS, does = Party A need to include a certain scope in the code flow request in = order to enable this part of the flow? How is the AS of Party B supposed to determine the token endpoint of = Party A=E2=80=99s AS? I think a figure of the overall process would help to understand the = concept.=20 kind regards, Torsten.=20 > Am 24.05.2018 um 22:28 schrieb internet-drafts@ietf.org: >=20 >=20 > 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. >=20 > Title : Reciprocal OAuth > Author : Dick Hardt > Filename : draft-ietf-oauth-reciprocal-00.txt > Pages : 4 > Date : 2018-05-24 >=20 > Abstract: > There are times when a user has a pair of protected resources that > would like to request access to each other. While OAuth flows > typically enable the user to grant a client access to a protected > resource, granting the inverse access requires an additional flow. > Reciprocal OAuth enables a more seamless experience for the user to > grant access to a pair of protected resources. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-00 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-00 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_AED7E529-88B6-4282-A411-357EB2AA4767 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNzE3MTUyMjM4WjAjBgkqhkiG9w0BCQQxFgQUozRWjT/V3A6L NvI+396PzH7tdJ4wgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBADnrUh6V8korllar2jiccY74WzHKCMK9bQ28368DFQ3IcYg2nkXw p7hr84Fy9ZeYKpEUFHqY1+M/1W2b8A1x76Sz7tnvpNqfoT5EXypT1FCLQuSEy18GjEJJvtxou6C+ SQV/jmWuxPEwhTsI8N6emuVT6J9W/0rawIuesnx6Foh7ayqbUgWurUfNyte6yHwizvFw74LUEzH2 1FKP0dHWDZQ3NDa7npARaY3niSu+P+DPnk/lKPHnQQeu1+8GOSP105J0tzFYco/Vdq0+q5CZHKI2 m+vYzX9veXGUitanvj9XdhAO06toNS6UKJPtFl/Z62fk7wURkmwuCXu+Vv72cnQAAAAAAAA= --Apple-Mail=_AED7E529-88B6-4282-A411-357EB2AA4767-- From nobody Tue Jul 17 09:00:01 2018 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 9129E130DCA for ; Tue, 17 Jul 2018 08:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 HL5e9qetenZY for ; Tue, 17 Jul 2018 08:59:57 -0700 (PDT) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.106]) (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 1E19B124BE5 for ; Tue, 17 Jul 2018 08:59:57 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ffSOI-0005VU-VG; Tue, 17 Jul 2018 17:59:55 +0200 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_BF7BDCF7-4A79-4892-9236-022C07C1AA02"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 17 Jul 2018 17:59:52 +0200 In-Reply-To: Cc: oauth@ietf.org To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.9.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 16:00:00 -0000 --Apple-Mail=_BF7BDCF7-4A79-4892-9236-022C07C1AA02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dick, I like the draft! It puts together some best practices relevant for = dynamic OAuth in a reasonable way. Some comments:=20 Section 2:=20 I appreciate the idea to let the resource determine its resource URI = (later used as aud of the access token). This will allow the RS to = segment and group its resources as needed. Section 3:=20 Don=E2=80=99t you think it could be a useful information to have the = resource URI available in the authorization flow?I would assume it could = have some additional meaning to the AS and could also be the context of = the scope. Section 4:=20 I think the client MUST authenticate using a PoP (asymmetric crypto = based) mechanisms due to the attack angle given in 6.3 Did you intentionally restricted the draft to single resources? I would = desire support for an integrated UI flow for authorizing access to = multiple resources at once. This makes sense in multi-service = deployments. Section 6.1.=20 I suggest you also refer to = https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06#section-3.= 7 for a comprehensive discussion of this threat. kind regards, Torsten. =20 > Am 12.06.2018 um 21:28 schrieb Dick Hardt : >=20 > Hey OAuth WG >=20 > I have worked with Nat and Brian to merge our concepts and those are = captured in the updated draft. >=20 > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ >=20 > We are hopeful the WG will adopt this draft as a WG document. >=20 > Any comments and feedback are welcome! >=20 > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_BF7BDCF7-4A79-4892-9236-022C07C1AA02 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNzE3MTU1OTUyWjAjBgkqhkiG9w0BCQQxFgQUnlFZ8o+UGiJJ dL1arLXwGHVtd2Qwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBABk8ATLLyStDa/pBPz1ua+JbJv//nmdod0/Wn5LcvPSCW2pvymtz nYx8v+J+0H444lXokDcPtqqb98k1gS7p8UeFBiHBL+NRv+VhMVjIdHWfBwlsh1sPv3OZ2ikv2bli DOcC8tcxefGTSGPZ6WAtSpSvjOuWVIBRboqngR/d/gd95cYWj/4wRy/eqqk1/4zApSc5AKw6ixwi j1CV3d8LEwD0rCbmwGPm4FxIGjpmuXVGWmXIDpO1i+IIFH/BJlYGtPq4/+V6+ZPjQxIhTFOxr8Jx F+2suNA9oP9xsK0a3uRgQTecmH1+uahetR+McNhXQZes2zgMcEpgLutzB6R71dEAAAAAAAA= --Apple-Mail=_BF7BDCF7-4A79-4892-9236-022C07C1AA02-- From nobody Tue Jul 17 09:01:22 2018 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 CC037130E27 for ; Tue, 17 Jul 2018 09:01: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, 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 XBvEBtteH8zq for ; Tue, 17 Jul 2018 09:01:17 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 96155130DCA for ; Tue, 17 Jul 2018 09:01:17 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id d14-v6so728467pfo.3 for ; Tue, 17 Jul 2018 09:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mA8ZbMqPh4YpLrsgSxOxWltSo98r2Zx/Z8K35Ai2KvA=; b=CH+SQslPCWvzVFijOY1UodhmA5oWfEunJzrd0wQMQnW6p0SvWis1f4aUID4LjTLmrG 9FcanDoXE4jigvaV/KKze48vVoG67sxo4mgkazio4Ruc1VHY9IRhmrS+T4Qa/TkYgn2/ Ss4WbWg5NrpRj5eKnZGAk9eKuTjTaQnDtL/mKRIXRtcTZ2o7gV4kDQrPgtXCIUEpbb2t QX20O1sSVUH3fJDVBSYRFRox/WQf8GqhwLzWbaMjCZfxQRAU87qY01xPMP09lyzJR9t9 guPurvXUuN6thVoi5+8zvwtgMMd0Q+pvKFKHBTBPi72hWlodgpIOcTEGWHsh8eaTbA6j i1Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mA8ZbMqPh4YpLrsgSxOxWltSo98r2Zx/Z8K35Ai2KvA=; b=lHzLXROeXx0dKrGUdDOmRiQtoh84BrNrVBC6qdl3NqqUrnP5o8vyAIpPz8Th4/n0CY sZBqKAcZNovdZcq0R3dJS19XehaM2sDRPwsl99zz2FUx2qbROyHnBkpY5v60nWRrbu/w Ip6bcicFuhGR9uHHghQDEzQILUL+8usiV5bMw01g5mBTDURROrV0LVZqrmaDkthT33uC AxZ2q3jN6mNpMbovsb/EU1sWpBv14S11BOZA2JZpF9oPrm85a1OFv9r/WCS0SfbAHa/5 ePnq8anpSWrvOhpqmDxmgctQj3+LhTbW40n4k2CI+CrKcbFRk5PJF3wQutxc9yI0FkVg Bkig== X-Gm-Message-State: AOUpUlE1JJuIYExRLVrS216CZshM+IutgdHkWm9hl/Y71RuLOL6tw6Y1 eQCej6BcUQum3Q4h+cU0ufpXyJJBt2CX1HSXG5w= X-Google-Smtp-Source: AAOMgpfrXjQDtHc5e0N4IaVq8pf8m4x5YdXTbUh3VEMF6dcSB6Q88BYOoYFa//tG/ihVNrqib8XoYCdolqA7H1KTecI= X-Received: by 2002:a63:a347:: with SMTP id v7-v6mr2106170pgn.182.1531843276959; Tue, 17 Jul 2018 09:01:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Tue, 17 Jul 2018 09:00:56 -0700 (PDT) In-Reply-To: <52D0886F-C7B3-4F98-B1CE-70E8406656D5@lodderstedt.net> References: <152719369843.5001.6781345939306593672@ietfa.amsl.com> <52D0886F-C7B3-4F98-B1CE-70E8406656D5@lodderstedt.net> From: Dick Hardt Date: Tue, 17 Jul 2018 12:00:56 -0400 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: multipart/alternative; boundary="0000000000005ff52b0571340e69" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 16:01:21 -0000 --0000000000005ff52b0571340e69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review Torsten. All good points to be clarified in the doc. Responses inserted ... On Tue, Jul 17, 2018 at 11:22 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Dick, > > I gave you draft a read and came up with the following questions: > > Section 2: How does Party A know it is supposed to conduct a reciprocal > OAuth flow if Party B does not indicate so in the authorization response? > Out of band configuration. Will clarify in next version. > > Section 3 > > Party A is supposed to call the token endpoint of Party B using an > authorization code generated by Party A. How does Party B interpret this > code? Or does it just send this code back to Party A to obtain its access > token for A? > Yes, per last sentence in Section 3. What language would clarify that? > > Party B uses the access token issued to Party A in the first part of the > flow (ordinary OAuth code flow) to identify the respective user account > with Party B. Since the AS consumes its access token as an RS, does Party= A > need to include a certain scope in the code flow request in order to enab= le > this part of the flow? > Party A is using its own access token for context. Party B is not accessing the user context / account. > > How is the AS of Party B supposed to determine the token endpoint of Part= y > A=E2=80=99s AS? > Same as Party A learns Party B's token endpoint. In practice, the flow could be started by either party. Both can initiate and complete. I'll clarify in the next version. > > I think a figure of the overall process would help to understand the > concept. > It is pretty much the same as OAuth with one extra flow. I can add if that would help. > > kind regards, > Torsten. > > > Am 24.05.2018 um 22:28 schrieb internet-drafts@ietf.org: > > > > > > 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 : Reciprocal OAuth > > Author : Dick Hardt > > Filename : draft-ietf-oauth-reciprocal-00.txt > > Pages : 4 > > Date : 2018-05-24 > > > > Abstract: > > There are times when a user has a pair of protected resources that > > would like to request access to each other. While OAuth flows > > typically enable the user to grant a client access to a protected > > resource, granting the inverse access requires an additional flow. > > Reciprocal OAuth enables a more seamless experience for the user to > > grant access to a pair of protected resources. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-00 > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-00 > > > > > > 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/ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --0000000000005ff52b0571340e69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review Torsten. All good points to be clari= fied in the doc. Responses inserted ...

On Tue, Jul 17, 2018 at 11:22 AM, Torsten Lodderstedt= <torsten@lodderstedt.net> wrote:
Hi Dick,

I gave you draft a read and came up with the following questions:

Section 2: How does Party A know it is supposed to conduct a reciprocal OAu= th flow if Party B does not indicate so in the authorization response?
<= /blockquote>

Out of band configuration. Will clarify in = next version.
=C2=A0

Section 3

Party A is supposed to call the token endpoint of Party B using an authoriz= ation code generated by Party A. How does Party B interpret this code? Or d= oes it just send this code back to Party A to obtain its access token for A= ?

Yes, per last sentence in Section 3. = What language would clarify that?
=C2=A0

Party B uses the access token issued to Party A in the first part of the fl= ow (ordinary OAuth code flow) to identify the respective user account with = Party B. Since the AS consumes its access token as an RS, does Party A need= to include a certain scope in the code flow request in order to enable thi= s part of the flow?

Party A is using it= s own access token for context. Party B is not accessing the user context /= account.
=C2=A0

How is the AS of Party B supposed to determine the token endpoint of Party = A=E2=80=99s AS?

Same as Party A learns = Party B's token endpoint.

In practice, the flo= w could be started by either party. Both can initiate and complete. I'l= l clarify in the next version.
=C2=A0

I think a figure of the overall process would help to understand the concep= t.

It is pretty much the same as OAuth= with one extra flow. I can add if that would help.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
kind regards,
Torsten.

> Am 24.05.2018 um 22:28 schrieb internet-drafts@ietf.org:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol WG of the = IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Reciprocal OAuth
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = Dick Hardt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-reciprocal-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 4
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-05-24
>
> Abstract:
>=C2=A0 =C2=A0There are times when a user has a pair of protected resour= ces that
>=C2=A0 =C2=A0would like to request access to each other.=C2=A0 While OA= uth flows
>=C2=A0 =C2=A0typically enable the user to grant a client access to a pr= otected
>=C2=A0 =C2=A0resource, granting the inverse access requires an addition= al flow.
>=C2=A0 =C2=A0Reciprocal OAuth enables a more seamless experience for th= e user to
>=C2=A0 =C2=A0grant access to a pair of protected resources.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/= doc/draft-ietf-oauth-reciprocal/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draf= t-ietf-oauth-reciprocal-00
> https://datatracker.ietf.or= g/doc/html/draft-ietf-oauth-reciprocal-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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=


--0000000000005ff52b0571340e69-- From nobody Tue Jul 17 09:17:25 2018 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 ECCC1130F2C for ; Tue, 17 Jul 2018 09:17:11 -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 a6e9awp_m0TM for ; Tue, 17 Jul 2018 09:17:09 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 0FB88130E7F for ; Tue, 17 Jul 2018 09:17:09 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id e6-v6so659896pgv.2 for ; Tue, 17 Jul 2018 09:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UNB18PmKjlRcWmRxYDj/iej+4WcYtuevuGFU8nneBTY=; b=F2ow6a/Qf+yKfvgne9FcogOaZuSvsOQVVB1O4xZQttk4zlvWA36dz437VNs3DEhp8L vVqQGh1jqIy9uyRZsSJ07JlIY2nSNE1O6jyDx9d7GPlRQhKe0rmddJp7lMlUB7tcxGdT HnZwB25AK99tKH3iEuvQTA/yHqyTDgsIhYXPkUyiZkY/h59Pu+XwodIUgsxUbw95zrmp v2xk/p3zOBB67+Qze4Dc2qEoMsvloP0I2gsdrh5cSxIYTGnxMp5GDxErIdzHZ8/pX/Q7 Wi/igNmtlYIRxsb/6qNykrj/pTqYLKZpxYv9BT3QQ9L0ZWJZn/ClpJN9p3ReYWz7k0c5 4E6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UNB18PmKjlRcWmRxYDj/iej+4WcYtuevuGFU8nneBTY=; b=iCRNChM9vvH4Y7nioCt6GXOtxIRTS+rnpOUS7jB+hwjYNyYyoLBRSJOluWHQzMKGAx I5+bQ+SjourFbxH0qLLjdvLNGwetXlQTfgqtQdxzn494Xptase8jM6iGENaUCnNJoTgV cXjHGgAj44G0+H/7WDEvapr1K4lnx9DuYS6bS7lzE1hkhG7KPVVo6ZOCU1FWhG/Mry1H licix+JGJ9+82EMQW+s6jSL3JgkPpwLQKV6HV7w7sfL2Y899fn4DWJNCQ7dRX3cNB5+P lWWIqTdnZaYw/CGXlrxV7nbHWWRZ0z3bQNtANKS+4ww9YSlNPn2GEr/Lo3SVTFBb7mfQ UgrQ== X-Gm-Message-State: AOUpUlFEeMOzyVF6kt/Ql9u36L2iaxqHn+QwEqeLg8nHrgWmk/qXkpzx WHJem4Hoijc7/O4kOZqEThMz5VbLcBTL2wb0Bco= X-Google-Smtp-Source: AAOMgpeVHFdGbrKvrBwoPDKoGb2mvwV4rjgpIaVGpJMNUz+om3A/KVZT+bEzmTLKt02PmDr8B4OtLKc3xVDNVM9J9nM= X-Received: by 2002:a63:6243:: with SMTP id w64-v6mr2204033pgb.179.1531844228400; Tue, 17 Jul 2018 09:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Tue, 17 Jul 2018 09:16:47 -0700 (PDT) In-Reply-To: References: From: Dick Hardt Date: Tue, 17 Jul 2018 12:16:47 -0400 Message-ID: To: Torsten Lodderstedt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000015cbab0571344714" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 16:17:24 -0000 --00000000000015cbab0571344714 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review Torsten! ... comments inserted ... On Tue, Jul 17, 2018 at 11:59 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Dick, > > I like the draft! It puts together some best practices relevant for > dynamic OAuth in a reasonable way. > > Some comments: > > Section 2: > I appreciate the idea to let the resource determine its resource URI > (later used as aud of the access token). This will allow the RS to segmen= t > and group its resources as needed. > :) > > Section 3: > Don=E2=80=99t you think it could be a useful information to have the reso= urce URI > available in the authorization flow?I would assume it could have some > additional meaning to the AS and could also be the context of the scope. > I'm assuming you are referring to the Authorization Code Grant. Good call out that the resource URI would be useful in the redirect. The use cases that I have been working with have all been Client Credential Grants I currently don't know of a real world use case for the Authorization Code Grant for Distributed OAuth. > > Section 4: > I think the client MUST authenticate using a PoP (asymmetric crypto based= ) > mechanisms due to the attack angle given in 6.3 > Did you intentionally restricted the draft to single resources? yes > I would desire support for an integrated UI flow for authorizing access t= o > multiple resources at once. This makes sense in multi-service deployments= . > It could be. Would be great to get some real use cases for that in an Authorization Code Grant. > > Section 6.1. > I suggest you also refer to https://tools.ietf.org/html/ > draft-ietf-oauth-security-topics-06#section-3.7 for a comprehensive > discussion of this threat. > Thanks > > kind regards, > Torsten. > > > > Am 12.06.2018 um 21:28 schrieb Dick Hardt : > > > > Hey OAuth WG > > > > I have worked with Nat and Brian to merge our concepts and those are > captured in the updated draft. > > > > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ > > > > We are hopeful the WG will adopt this draft as a WG document. > > > > Any comments and feedback are welcome! > > > > /Dick > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --00000000000015cbab0571344714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review Torsten! ... comments inserted ...= =C2=A0

On Tue,= Jul 17, 2018 at 11:59 AM, Torsten Lodderstedt <torsten@lodderstedt.= net> wrote:
Hi Dick,

I like the draft! It puts together some best practices relevant for dynamic= OAuth in a reasonable way.

Some comments:

Section 2:
I appreciate the idea to let the resource determine its resource URI (later= used as aud of the access token). This will allow the RS to segment and gr= oup its resources as needed.

:)
=C2=A0

Section 3:
Don=E2=80=99t you think it could be a useful information to have the resour= ce URI available in the authorization flow?I would assume it could have som= e additional meaning to the AS and could also be the context of the scope.<= br>

I'm assuming you are referring to t= he Authorization Code Grant. Good call out that the resource URI would be u= seful in the redirect.=C2=A0

The use cases that I = have been working with have all been Client Credential Grants
I currently don't know of a real world use case for the Aut= horization Code Grant for Distributed OAuth.
=C2=A0

Section 4:
I think the client MUST authenticate using a PoP (asymmetric crypto based) = mechanisms due to the attack angle given in 6.3
Did you intentionally restricted the draft to single resources?

yes
=C2=A0
I would desire support for an integrated UI flow for authorizing access= to multiple resources at once. This makes sense in multi-service deploymen= ts.

It could be. Would be great to get = some real use cases for that in an Authorization Code Grant.
=C2= =A0

Section 6.1.
I suggest you also refer to https://tools.ietf.org/html/draft-ietf-oauth-security-topics-0= 6#section-3.7 for a comprehensive discussion of this threat.

Thanks
=C2=A0

kind regards,
Torsten.=C2=A0 =C2=A0


> Am 12.06.2018 um 21:28 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Hey OAuth WG
>
> I have worked with Nat and Brian to merge our concepts and those are c= aptured in the updated draft.
>
> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
>
> We are hopeful the WG will adopt this draft as a WG document.
>
> Any comments and feedback are welcome!
>
> /Dick
> __________________= _____________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=


--00000000000015cbab0571344714-- From nobody Tue Jul 17 10:33:41 2018 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 201D4130F13 for ; Tue, 17 Jul 2018 10:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 v1stRUabdF_e for ; Tue, 17 Jul 2018 10:33:34 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 9CB0B130FAE for ; Tue, 17 Jul 2018 10:33:33 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id e139-v6so1020369vkf.6 for ; Tue, 17 Jul 2018 10:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dJVOetSbEpFJI1i7O+DwKiGBJ0p3zkBiZO5a2dmoaiQ=; b=tQaXFyUixiRjEOPgSLB8q5GN6xgla9QnJCb0ZR+oP7Zz54ChOVI0EACwjiY0Oh2XsM 2fxb9zhFcqMmLvjPMKX6HbJY0g2hS9dwi9JnWoBW3F22laXNqyTv9nDFhQd5DPZq0SeZ M77ZgtJwyN0B4Csl9L7BJnvq/BCEuXPqYup/SlU+QVbTb+GFG1u4fAC3hLVKhYhCQ7yt EnjCbeBzPao1qomUSgcFHuww/QsQDGjTRsPgRyi1bnkrL2oRVf98uYsndG1DLbCAg+t0 j5fyIunbX7xPvolow2Lzv+fNdettt3JSlmsxCBu57sC9I/t/glTGP6SDVchM9V5T4P5/ KQUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dJVOetSbEpFJI1i7O+DwKiGBJ0p3zkBiZO5a2dmoaiQ=; b=ffXuBe3c3QEaUSaFro6wioAmbX1ldmEHkqKsqgOV3YJ3I0rCPgimGZZImOXUhigxgC XWuBwxx1rpfaKvvZrcxxbs17hdy9fkKelH6NFlD2VhNz81F+sMs9ghAQwXs1f2vG4J7F 2fLqknLTEmPH/Ke/dODHqmjjIHHmfWEVl95igHQvD2bQRdYP+btzZXjtVhhDGhoOH6eR uRZiEBqtIVWO7xEGWdV6mCIeDL41wRR3TrFiezgw/y1HUhNfcsF9OAPFHu3a8yL/4r8C z9D/CjxqCSMT96wk16m2De87FyN9AyVnckgW7y1bUdR/yhBisFGNZw4bdXkTaP6ICnEb RNOg== X-Gm-Message-State: AOUpUlH9PO5l9EFzPEL7On7/cOVCspI1JAMc6VKOz7y3tx/5MKOFNWio yJhFvpBoqgdh7hw2lWfG9kAZMXpxD/wc4QYgI1H7PemcI04= X-Google-Smtp-Source: AAOMgpcS2d+gdXNah9GchIkhni3ZUnXymhgPNFNm7s+30uIWFFQSklgjuWuPaiRpZv/ttGaNtb/8Rb3Z5LkSAnMAFRA= X-Received: by 2002:a1f:6b11:: with SMTP id g17-v6mr1464693vkc.82.1531848811874; Tue, 17 Jul 2018 10:33:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:6383:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 10:33:11 -0700 (PDT) In-Reply-To: References: <153021689405.18540.5214482725778765448@ietfa.amsl.com> From: William Denniss Date: Tue, 17 Jul 2018 10:33:11 -0700 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: multipart/alternative; boundary="00000000000048965c05713558ce" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 17:33:37 -0000 --00000000000048965c05713558ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten, On Tue, Jul 17, 2018 at 7:57 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi William, > > please find below my review feedback. > > First of all, I think you managed to come up with the minimal extension > needed to address a very relevant use case. Thanks! > Glad you like it! Thanks for reviewing. > - Section 5, last paragraph. > > "the new refresh token issued in the Access Token Response (Section 4.1.4 > of ) SHOULD include authorization for the scopes in the previous grant.= =E2=80=9C > > Wouldn=E2=80=99t it be better to make that a MUST? Otherwise the client m= ust > assume the AS decides to not include all previously granted scopes, which > in turn means the client must keep older grants (and hope the AS dd not > automatically revolve it). > I was torn about this. From a protocol perspective you're not implementing the protocol if you don't do that, so it should be a MUST. However, we need to be careful that we defer to the provider when it comes to what authorization is included as this is always their discretion. I'll think of a better way to word this so that it can be a MUST while still not limiting the provider's discretion. > > - Section 6.1.1 > > The section describes how a client should handle denial for incremental > authorizations. How is the AS supposed to handle it? From the text one > could deduce the AS should not discard any pre-existing granted scopes. I= s > that correct? Would it make sense to explicitly state that? > Good point. That section is mostly talking about the client, I'll add a section for the server. I agree, the normal behavior would not be to revoke previously granted scopes (which is how Google implements it). Best, William > > Am 28.06.2018 um 22:14 schrieb internet-drafts@ietf.org: > > > > > > 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 Incremental Authorization > > Author : William Denniss > > Filename : draft-ietf-oauth-incremental-authz-00.txt > > Pages : 8 > > Date : 2018-06-28 > > > > Abstract: > > OAuth 2.0 authorization requests that include every scope the client > > might ever need can result in over-scoped authorization and a sub- > > optimal end-user consent experience. This specification enhances the > > OAuth 2.0 authorization protocol by adding incremental authorization, > > the ability to request specific authorization scopes as needed, when > > they're needed, removing the requirement to request every possible > > scope that might be needed upfront. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-00 > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth- > incremental-authz-00 > > > > > > 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/ > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --00000000000048965c05713558ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Torsten,

On Tue, Jul 17, 2018 at 7:57 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi William,

please find below my review feedback.

First of all, I think you managed to come up with the minimal extension nee= ded to address a very relevant use case. Thanks!

<= /div>
Glad you like it! Thanks for reviewing.
=C2=A0
- Section 5, last paragraph.

"the new refresh token issued in the Access Token Response (Section 4.= 1.4 of ) SHOULD include authorization for the scopes in the previous grant.= =E2=80=9C

Wouldn=E2=80=99t it be better to make that a MUST? Otherwise the client mus= t assume the AS decides to not include all previously granted scopes, which= in turn means the client must keep older grants (and hope the AS dd not au= tomatically revolve it).

I was torn abo= ut this. From a protocol perspective you're not implementing the protoc= ol if you don't do that, so it should be a MUST. However, we need to be= careful that we defer to the provider when it comes to what authorization = is included as this is always their discretion.=C2=A0 I'll think of a b= etter way to word this so that it can be a MUST while still not limiting th= e provider's=C2=A0discretion.
=C2=A0

- Section 6.1.1

The section describes how a client should handle denial for incremental aut= horizations. How is the AS supposed to handle it? From the text one could d= educe the AS should not discard any pre-existing granted scopes. Is that co= rrect? Would it make sense to explicitly state that?
<= br>
Good point. That section is mostly talking about the client, = I'll add a section for the server. I agree, the normal behavior would n= ot be to revoke previously granted scopes (which is how Google implements i= t).

Best,
William


> Am 28.06.2018 um 22:14 schrieb internet-drafts@ietf.org:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol WG of the = IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: OAuth 2.0 Incremental Authorization
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = William Denniss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-incremental-authz-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-06-28
>
> Abstract:
>=C2=A0 =C2=A0OAuth 2.0 authorization requests that include every scope = the client
>=C2=A0 =C2=A0might ever need can result in over-scoped authorization an= d a sub-
>=C2=A0 =C2=A0optimal end-user consent experience.=C2=A0 This specificat= ion enhances the
>=C2=A0 =C2=A0OAuth 2.0 authorization protocol by adding incremental aut= horization,
>=C2=A0 =C2=A0the ability to request specific authorization scopes as ne= eded, when
>=C2=A0 =C2=A0they're needed, removing the requirement to request ev= ery possible
>=C2=A0 =C2=A0scope that might be needed upfront.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.or= g/doc/draft-ietf-oauth-incremental-authz/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-00
> https://datatracker.= ietf.org/doc/html/draft-ietf-oauth-incremental-authz-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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=


--00000000000048965c05713558ce-- From nobody Tue Jul 17 10:48:39 2018 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 9572D130FF3; Tue, 17 Jul 2018 10:48:36 -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.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153184971656.12663.1610083508356735781@ietfa.amsl.com> Date: Tue, 17 Jul 2018 10:48:36 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 17:48:37 -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 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-10.txt Pages : 21 Date : 2018-07-17 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 sever 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-10 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-10 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 Tue Jul 17 10:51:35 2018 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 7066613104C for ; Tue, 17 Jul 2018 10:51:24 -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=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 9ydHBgXOKmsa for ; Tue, 17 Jul 2018 10:51:21 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 1517D131007 for ; Tue, 17 Jul 2018 10:51:21 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id q4-v6so1736791iob.2 for ; Tue, 17 Jul 2018 10:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=A4v1dDPRupzUI0G1qukZeixvJrB69LkzAjTz42kSb1w=; b=dkKaI7OrYe00xvTdWWNYsMAuY3VPflRqs/1EE8IH3jG/kYxiLmjdBXYeuZ/Ayp+VeC B6vQvoXh4eQ9u8Y6GiUABF4V55WljqEJwaT0iJdrLDFGjrgYnKR8M5TY5apVFMash9V4 Dmnubtu+INUZJGjgu+8pozICM/+2bV3Xkzpg8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=A4v1dDPRupzUI0G1qukZeixvJrB69LkzAjTz42kSb1w=; b=TgUuzLkL+G4KmzHw9tKAkmiqU01R/B8Bww4qZEFKYg7lFAKTOyTjkYjP6k9piW6rmb nxxWX4yrpJD3zF1KdR1YZ/Nu1/JfT529l0kI5ZpjLMKuaBGGfFX8h3Ph6ibB/OCUiYG7 w6SUvKunGmGx6mZrULtSjblc6S8TxVuDJyBZ3gYfRPbBB8pJRmKldFXOj1WUkJbwXrRb yOm41mqAXPhIS7vapreSlKn2/V4N5sgqEVVMOmjrGF+Fq2hRDdBsOGQ18sWo7MkqVIP4 97nQ7MOl36IK6WVSqjF2iVh9Q0oBUy7rvvZUvYD/lBzHnDvhmoF/jNzt8dVtBzQf+K/i qisg== X-Gm-Message-State: AOUpUlHEl6/uzY/7KtY4e111YWR4jh0mhPyAvk++FttjqqrnKzzjXQQK WwD6RdA4PFd+L6IKFnQ1XV3YDISmuMGCFzsPQ1mySR6kdoQxP3bgQrGiJAB6dSnkNMNSveyfSrQ 6HWiFnBN2fLYZ/cQp X-Google-Smtp-Source: AA+uWPxSDowAUuxqwTDdH3pWH/bNGfKpjdfApgEREmU6hDw+ydEdlj7TVyP6lq5/rl9reyjknrs5pQ+Ow+yDh97fEb4= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr2316940ioa.168.1531849880040; Tue, 17 Jul 2018 10:51:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6d18:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 10:50:49 -0700 (PDT) In-Reply-To: <153184971656.12663.1610083508356735781@ietfa.amsl.com> References: <153184971656.12663.1610083508356735781@ietfa.amsl.com> From: Brian Campbell Date: Tue, 17 Jul 2018 11:50:49 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000f3132b057135971c" Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 17:51:34 -0000 --000000000000f3132b057135971c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable -10 just updates the draft-ietf-oauth-discovery reference to RFC8414 now that 8414 is an actual RFC ---------- Forwarded message ---------- From: Date: Tue, Jul 17, 2018 at 11:48 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-10.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org 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 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-10.txt Pages : 21 Date : 2018-07-17 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 sever 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-10 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-mtls-10 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 --=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._ --000000000000f3132b057135971c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
-10 just updates the draft-ietf-oauth-discovery refer= ence to RFC8414 now that=C2=A08414 is an actual RFC

---------- Forwarded message -------= ---
From: <internet-drafts@ietf.org>
Date: Tue, Jul 17, 2018 at 11:48 AM
Subject: [OAUTH-WG] I-D Actio= n: draft-ietf-oauth-mtls-10.txt
To: i-d-announce@ietf.org
Cc: oau= th@ietf.org



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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access To= kens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Campbell
=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 John Bradley
=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 Nat Sakimura
=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 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-mtls-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-07-17

Abstract:
=C2=A0 =C2=A0This document describes OAuth client authentication and certif= icate
=C2=A0 =C2=A0bound access tokens using mutual Transport Layer Security (TLS= )
=C2=A0 =C2=A0authentication with X.509 certificates.=C2=A0 OAuth clients ar= e provided a
=C2=A0 =C2=A0mechanism for authentication to the authorization sever using = mutual
=C2=A0 =C2=A0TLS, based on either self-signed certificates or public key =C2=A0 =C2=A0infrastructure (PKI).=C2=A0 OAuth authorization servers are pr= ovided a
=C2=A0 =C2=A0mechanism for binding access tokens to a client's mutual T= LS
=C2=A0 =C2=A0certificate, and OAuth protected resources are provided a meth= od for
=C2=A0 =C2=A0ensuring that such an access token presented to it was issued = to the
=C2=A0 =C2=A0client presenting the token.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-i= etf-oauth-mtls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oaut= h-mtls-10
https://datatracker.ietf.org/doc/= html/draft-ietf-oauth-mtls-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-oauth-mtls-10


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


<= 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. --000000000000f3132b057135971c-- From nobody Tue Jul 17 11:57:10 2018 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 CC8C5130F24 for ; Tue, 17 Jul 2018 11:57: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, 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 msm2_47VrgV9 for ; Tue, 17 Jul 2018 11:56:58 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 6EECB130DF3 for ; Tue, 17 Jul 2018 11:56:58 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id l7-v6so1916926ioj.1 for ; Tue, 17 Jul 2018 11:56:58 -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=O7vN6B2p+JlpN+dNbBRRZuzTAodHzT7jXoSuwOFOR+M=; b=aLMicLRtjU3lpwi68X3XBFmEhCpyO+RJ3tgetqh+ltAJM2aUqftduwYPFgn9N1C7jD 8RFswtjXxmNTt3RzRUiAKb2fp4EQrEoGO2bLqfYrP0xhoC9ZT6lFufMlzP8lLz8smzFz ISSRLUK+hq0O+NgXtLjfGOiLKmoZwKrdV1M+2E9fB6tXb2mYo/XO4L/MGT8dKS30gAJw JDseYwsY9ouKp/jl8hTZPhSIlnTv1zUy7U0p8S5Y81BFJ7BdQCoxX5Y4NfRM9xOx6U96 hbobMh84pz0nEebCVF9g91MGKYEuupP6mLnilsnGEG5j9pOp0+2F1z1ekhYEPPUx8qWT XN+g== 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=O7vN6B2p+JlpN+dNbBRRZuzTAodHzT7jXoSuwOFOR+M=; b=PyThNIxdbpq7MQr1yt2JzYvFIJT0zVhjo6/n7uVx834CIMfnVhh1EQKROUOVqdGH+t 3ItXfqtceqVQebY0yHptZlwgFcgUBXysJieY8WVClfvAkRF/3NihMrBpVtKUZ7y5mlK2 0YPAXWixXyTFcHMTHYIhyynBmjFjUV4AYhhJFQFj3N5PUF69yuAVswOErr6QY9/NM7fd f69YXbqzYHR77RnbKkUqluSodZW9ytFG2C69+jGDszo4sTBM1SgOoYfHT7tGEVzzCnsb /tt73ffOcjoQ1xSwHFWL5icSZS+VhpZjKj+h3uwlnzfmZZW/Gk+W0VYi/X+FU1zf7B7Y qDhw== X-Gm-Message-State: AOUpUlGK0t/sI7NiO3dgBZXY1rzPPay2qZKEvgIplIwRC71K0BtnU9+J NQVQBiZivt5ZJpHJW8CK3ta3EZvWDIcmSzEpR0O2deq6 X-Google-Smtp-Source: AA+uWPzJF7IFRCtK/yGNCuZv+6HF7b2NbtCcu9k2LErBK1tN2cXoMLenlpZwFOF6OXHTn91N2i5ZPYYCsoOK/hkq+eI= X-Received: by 2002:a6b:410a:: with SMTP id n10-v6mr2654838ioa.0.1531853817834; Tue, 17 Jul 2018 11:56:57 -0700 (PDT) MIME-Version: 1.0 References: <152719369843.5001.6781345939306593672@ietfa.amsl.com> <52D0886F-C7B3-4F98-B1CE-70E8406656D5@lodderstedt.net> In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 17 Jul 2018 14:56:46 -0400 Message-ID: To: Dick Hardt Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000a8f1af05713682ae" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 18:57:07 -0000 --000000000000a8f1af05713682ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, I too reviewed the document, and had similar questions in mind. I agree with Torsten, a figure would make it easier to follow and understand. Regards, Rifaat On Tue, Jul 17, 2018 at 12:01 PM Dick Hardt wrote: > Thanks for the review Torsten. All good points to be clarified in the doc= . > Responses inserted ... > > On Tue, Jul 17, 2018 at 11:22 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Dick, >> >> I gave you draft a read and came up with the following questions: >> >> Section 2: How does Party A know it is supposed to conduct a reciprocal >> OAuth flow if Party B does not indicate so in the authorization response= ? >> > > Out of band configuration. Will clarify in next version. > > >> >> Section 3 >> >> Party A is supposed to call the token endpoint of Party B using an >> authorization code generated by Party A. How does Party B interpret this >> code? Or does it just send this code back to Party A to obtain its acces= s >> token for A? >> > > Yes, per last sentence in Section 3. What language would clarify that? > > >> >> Party B uses the access token issued to Party A in the first part of the >> flow (ordinary OAuth code flow) to identify the respective user account >> with Party B. Since the AS consumes its access token as an RS, does Part= y A >> need to include a certain scope in the code flow request in order to ena= ble >> this part of the flow? >> > > Party A is using its own access token for context. Party B is not > accessing the user context / account. > > >> >> How is the AS of Party B supposed to determine the token endpoint of >> Party A=E2=80=99s AS? >> > > Same as Party A learns Party B's token endpoint. > > In practice, the flow could be started by either party. Both can initiate > and complete. I'll clarify in the next version. > > >> >> I think a figure of the overall process would help to understand the >> concept. >> > > It is pretty much the same as OAuth with one extra flow. I can add if tha= t > would help. > > >> >> kind regards, >> Torsten. >> >> > Am 24.05.2018 um 22:28 schrieb internet-drafts@ietf.org: >> > >> > >> > 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 : Reciprocal OAuth >> > Author : Dick Hardt >> > Filename : draft-ietf-oauth-reciprocal-00.txt >> > Pages : 4 >> > Date : 2018-05-24 >> > >> > Abstract: >> > There are times when a user has a pair of protected resources that >> > would like to request access to each other. While OAuth flows >> > typically enable the user to grant a client access to a protected >> > resource, granting the inverse access requires an additional flow. >> > Reciprocal OAuth enables a more seamless experience for the user to >> > grant access to a pair of protected resources. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ >> > >> > There are also htmlized versions available at: >> > https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-00 >> > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-00 >> > >> > >> > 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/ >> > >> > _______________________________________________ >> > 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 > --000000000000a8f1af05713682ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,

I too reviewed the document, a= nd had similar questions in mind.
I agree with Torsten, a figure = would make it easier to follow and understand.

Reg= ards,
=C2=A0Rifaat


On Tue, Jul 17, 2018 at 12:01 PM Dick Hardt <= ;dick.hardt@gmail.com> wrote= :
Thanks for the r= eview Torsten. All good points to be clarified in the doc. Responses insert= ed ...

On Tue, Jul= 17, 2018 at 11:22 AM, Torsten Lodderstedt <torsten@lodderstedt.net<= /a>> wrote:
Hi Dick,

I gave you draft a read and came up with the following questions:

Section 2: How does Party A know it is supposed to conduct a reciprocal OAu= th flow if Party B does not indicate so in the authorization response?
<= /blockquote>

Out of band configuration. Will clarify in = next version.
=C2=A0

Section 3

Party A is supposed to call the token endpoint of Party B using an authoriz= ation code generated by Party A. How does Party B interpret this code? Or d= oes it just send this code back to Party A to obtain its access token for A= ?

Yes, per last sentence in Section 3. = What language would clarify that?
=C2=A0

Party B uses the access token issued to Party A in the first part of the fl= ow (ordinary OAuth code flow) to identify the respective user account with = Party B. Since the AS consumes its access token as an RS, does Party A need= to include a certain scope in the code flow request in order to enable thi= s part of the flow?

Party A is using it= s own access token for context. Party B is not accessing the user context /= account.
=C2=A0

How is the AS of Party B supposed to determine the token endpoint of Party = A=E2=80=99s AS?

Same as Party A learns = Party B's token endpoint.

In practice, the flo= w could be started by either party. Both can initiate and complete. I'l= l clarify in the next version.
=C2=A0

I think a figure of the overall process would help to understand the concep= t.

It is pretty much the same as OAuth= with one extra flow. I can add if that would help.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
kind regards,
Torsten.

> Am 24.05.2018 um 22:28 schrieb internet-drafts@ietf.org:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol WG of the = IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Reciprocal OAuth
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = Dick Hardt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-reciprocal-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 4
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-05-24
>
> Abstract:
>=C2=A0 =C2=A0There are times when a user has a pair of protected resour= ces that
>=C2=A0 =C2=A0would like to request access to each other.=C2=A0 While OA= uth flows
>=C2=A0 =C2=A0typically enable the user to grant a client access to a pr= otected
>=C2=A0 =C2=A0resource, granting the inverse access requires an addition= al flow.
>=C2=A0 =C2=A0Reciprocal OAuth enables a more seamless experience for th= e user to
>=C2=A0 =C2=A0grant access to a pair of protected resources.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/d= raft-ietf-oauth-reciprocal/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-iet= f-oauth-reciprocal-00
> https://datatracker.ietf.or= g/doc/html/draft-ietf-oauth-reciprocal-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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
--000000000000a8f1af05713682ae-- From nobody Tue Jul 17 12:14:53 2018 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 38B91130E08 for ; Tue, 17 Jul 2018 12:14: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 DIEgB3cTucc8 for ; Tue, 17 Jul 2018 12:14:49 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 F2F5E130DF3 for ; Tue, 17 Jul 2018 12:14:48 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id p23-v6so844461pgv.13 for ; Tue, 17 Jul 2018 12:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5pz4bB5pLh8VN7Jeeb51DNtl33MLnJAE7AUw+d3qi7g=; b=U/ou3X8Ia42btXkAcQO8Lfm77wt3maap4FbhGnpURJSp1wUYDwGhbJN2t3VmDME8PQ 2jQ2sYjfyAl0w04kLW/LhwEpuN0jRzsfoaPYeGd/wolmtl14JvoYO9RO8Nau9xd5Lvh1 pzVfocx1zK0LnyaeGDLGjD+uWYYQb24Pc5zJadhqewj26npO21E0rD6TFgpUhrF+o9mR /z8t+a3XMch3LppsSSSQbnSf48HztdBPoROUjXDMYJVS2AELPNjXrG7pZOPVy4Qry0a5 6MjEv1Rzsf/AMelSkDqJKOC3QZrTDgVguqM93wdKfyStLN4uqLgoI2XSsAPHmX0/RFb8 qGlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5pz4bB5pLh8VN7Jeeb51DNtl33MLnJAE7AUw+d3qi7g=; b=p5h+CirzEEqAqw2AGKJyEBiuphI6EffD15p6dQEjNoMdf0F8nBA6s98m6SaVOEYqFk ntymOusBZ7IJWGvP7Btl8B29BeqRRAvgWSbca92xzbfvdrsM4oa0aScEP14t2Z86JSMO /wj+RsA3BaQhZntprJnxfKQFrSZdJXo3Cgw+xRF99xEOxSo/JA00vl2fvnMC3kqCXlyT J5CCmoH2vRrxeRJzezhEn/eMqfk3bUo9KqmUoesaaFYN3sR+sdZjb8C8u8v4bHAoZEpU O4pNAAegwlv1L5UxNFkq/4Q95tsyP4EtODfMOHdRrbJx4V8YePYhJv+fcVKNABXHihP3 CzjA== X-Gm-Message-State: AOUpUlEulDZsAhNczo9nMuoJVMGDCbWeVumAwGChuxw4UJ1E2mBlOEli cyB9x62T8pI4cMaHfFxiry8B5ZAYOZmIfwG2eBQ= X-Google-Smtp-Source: AAOMgpcpTxIeYAeUPgjohFMyjqsY6ClQGjj1e6XJEhNKKEuYRm02whGHs2nZ6/qHKK0NUM4nwhFgRG18bRoKcVj5iH8= X-Received: by 2002:a65:62ce:: with SMTP id m14-v6mr2758165pgv.407.1531854888444; Tue, 17 Jul 2018 12:14:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Tue, 17 Jul 2018 12:14:27 -0700 (PDT) In-Reply-To: References: <152719369843.5001.6781345939306593672@ietfa.amsl.com> <52D0886F-C7B3-4F98-B1CE-70E8406656D5@lodderstedt.net> From: Dick Hardt Date: Tue, 17 Jul 2018 15:14:27 -0400 Message-ID: To: Rifaat Shekh-Yusef Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000792863057136c2f1" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 19:14:52 -0000 --000000000000792863057136c2f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the feedback! I'll break out my ASCII art skills. On Tue, Jul 17, 2018 at 2:56 PM, Rifaat Shekh-Yusef wrote: > Hi Dick, > > I too reviewed the document, and had similar questions in mind. > I agree with Torsten, a figure would make it easier to follow and > understand. > > Regards, > Rifaat > > > On Tue, Jul 17, 2018 at 12:01 PM Dick Hardt wrote: > >> Thanks for the review Torsten. All good points to be clarified in the >> doc. Responses inserted ... >> >> On Tue, Jul 17, 2018 at 11:22 AM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> Hi Dick, >>> >>> I gave you draft a read and came up with the following questions: >>> >>> Section 2: How does Party A know it is supposed to conduct a reciprocal >>> OAuth flow if Party B does not indicate so in the authorization respons= e? >>> >> >> Out of band configuration. Will clarify in next version. >> >> >>> >>> Section 3 >>> >>> Party A is supposed to call the token endpoint of Party B using an >>> authorization code generated by Party A. How does Party B interpret thi= s >>> code? Or does it just send this code back to Party A to obtain its acce= ss >>> token for A? >>> >> >> Yes, per last sentence in Section 3. What language would clarify that? >> >> >>> >>> Party B uses the access token issued to Party A in the first part of th= e >>> flow (ordinary OAuth code flow) to identify the respective user account >>> with Party B. Since the AS consumes its access token as an RS, does Par= ty A >>> need to include a certain scope in the code flow request in order to en= able >>> this part of the flow? >>> >> >> Party A is using its own access token for context. Party B is not >> accessing the user context / account. >> >> >>> >>> How is the AS of Party B supposed to determine the token endpoint of >>> Party A=E2=80=99s AS? >>> >> >> Same as Party A learns Party B's token endpoint. >> >> In practice, the flow could be started by either party. Both can initiat= e >> and complete. I'll clarify in the next version. >> >> >>> >>> I think a figure of the overall process would help to understand the >>> concept. >>> >> >> It is pretty much the same as OAuth with one extra flow. I can add if >> that would help. >> >> >>> >>> kind regards, >>> Torsten. >>> >>> > Am 24.05.2018 um 22:28 schrieb internet-drafts@ietf.org: >>> > >>> > >>> > 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 : Reciprocal OAuth >>> > Author : Dick Hardt >>> > Filename : draft-ietf-oauth-reciprocal-00.txt >>> > Pages : 4 >>> > Date : 2018-05-24 >>> > >>> > Abstract: >>> > There are times when a user has a pair of protected resources that >>> > would like to request access to each other. While OAuth flows >>> > typically enable the user to grant a client access to a protected >>> > resource, granting the inverse access requires an additional flow. >>> > Reciprocal OAuth enables a more seamless experience for the user to >>> > grant access to a pair of protected resources. >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ >>> > >>> > There are also htmlized versions available at: >>> > https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-00 >>> > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-00 >>> > >>> > >>> > 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/ >>> > >>> > _______________________________________________ >>> > 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 >> > --000000000000792863057136c2f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the feedback!

I'll break= out my ASCII art skills.

On Tue, Jul 17, 2018 at 2:56 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi Dick,

I too reviewed the docum= ent, and had similar questions in mind.
I agree with Torsten, a f= igure would make it easier to follow and understand.

Regards,
=C2=A0Rifaat


O= n Tue, Jul 17, 2018 at 12:01 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=
Thanks for the review Torst= en. All good points to be clarified in the doc. Responses inserted ...

On Tue, Jul 17, 2018 a= t 11:22 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Dick,

I gave you draft a read and came up with the following questions:

Section 2: How does Party A know it is supposed to conduct a reciprocal OAu= th flow if Party B does not indicate so in the authorization response?
<= /blockquote>

Out of band configuration. Will clarify in = next version.
=C2=A0

Section 3

Party A is supposed to call the token endpoint of Party B using an authoriz= ation code generated by Party A. How does Party B interpret this code? Or d= oes it just send this code back to Party A to obtain its access token for A= ?

Yes, per last sentence in Section 3. = What language would clarify that?
=C2=A0

Party B uses the access token issued to Party A in the first part of the fl= ow (ordinary OAuth code flow) to identify the respective user account with = Party B. Since the AS consumes its access token as an RS, does Party A need= to include a certain scope in the code flow request in order to enable thi= s part of the flow?

Party A is using it= s own access token for context. Party B is not accessing the user context /= account.
=C2=A0

How is the AS of Party B supposed to determine the token endpoint of Party = A=E2=80=99s AS?

Same as Party A learns = Party B's token endpoint.

In practice, the flo= w could be started by either party. Both can initiate and complete. I'l= l clarify in the next version.
=C2=A0

I think a figure of the overall process would help to understand the concep= t.

It is pretty much the same as OAuth= with one extra flow. I can add if that would help.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
kind regards,
Torsten.

> Am 24.05.2018 um 22:28 schrieb internet-drafts@ietf.org:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Web Authorization Protocol WG of the = IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Reciprocal OAuth
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = Dick Hardt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-oauth-reciprocal-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 4
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-05-24
>
> Abstract:
>=C2=A0 =C2=A0There are times when a user has a pair of protected resour= ces that
>=C2=A0 =C2=A0would like to request access to each other.=C2=A0 While OA= uth flows
>=C2=A0 =C2=A0typically enable the user to grant a client access to a pr= otected
>=C2=A0 =C2=A0resource, granting the inverse access requires an addition= al flow.
>=C2=A0 =C2=A0Reciprocal OAuth enables a more seamless experience for th= e user to
>=C2=A0 =C2=A0grant access to a pair of protected resources.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/= doc/draft-ietf-oauth-reciprocal/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draf= t-ietf-oauth-reciprocal-00
> https://datatracker.ietf.or= g/doc/html/draft-ietf-oauth-reciprocal-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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

--000000000000792863057136c2f1-- From nobody Tue Jul 17 13:27:08 2018 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 A1658130EF2 for ; Tue, 17 Jul 2018 13:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 mfEigMjz64s4 for ; Tue, 17 Jul 2018 13:27:03 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (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 18144130E62 for ; Tue, 17 Jul 2018 13:27:02 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ffWYm-0008I6-3b; Tue, 17 Jul 2018 22:27:00 +0200 From: Torsten Lodderstedt Message-Id: <629FEF02-7853-4FA5-8895-0851809C8BA0@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_BDFB3C57-BF63-418B-BF85-0E38982C4E24"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 17 Jul 2018 22:26:57 +0200 In-Reply-To: Cc: oauth To: William Denniss References: <153021689405.18540.5214482725778765448@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:27:07 -0000 --Apple-Mail=_BDFB3C57-BF63-418B-BF85-0E38982C4E24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi William,=20 I think it would make sense to add AS metadata fields, which the AS can = use to advertise support for include_granted_scopes and existing_grant. kind regards, Torsten.=20 > Am 17.07.2018 um 19:33 schrieb William Denniss : >=20 > Hi Torsten, >=20 > On Tue, Jul 17, 2018 at 7:57 AM, Torsten Lodderstedt = wrote: > Hi William,=20 >=20 > please find below my review feedback. >=20 > First of all, I think you managed to come up with the minimal = extension needed to address a very relevant use case. Thanks! >=20 > Glad you like it! Thanks for reviewing. > =20 > - Section 5, last paragraph.=20 >=20 > "the new refresh token issued in the Access Token Response (Section = 4.1.4 of ) SHOULD include authorization for the scopes in the previous = grant.=E2=80=9C >=20 > Wouldn=E2=80=99t it be better to make that a MUST? Otherwise the = client must assume the AS decides to not include all previously granted = scopes, which in turn means the client must keep older grants (and hope = the AS dd not automatically revolve it). >=20 > I was torn about this. =46rom a protocol perspective you're not = implementing the protocol if you don't do that, so it should be a MUST. = However, we need to be careful that we defer to the provider when it = comes to what authorization is included as this is always their = discretion. I'll think of a better way to word this so that it can be a = MUST while still not limiting the provider's discretion. > =20 >=20 > - Section 6.1.1 >=20 > The section describes how a client should handle denial for = incremental authorizations. How is the AS supposed to handle it? =46rom = the text one could deduce the AS should not discard any pre-existing = granted scopes. Is that correct? Would it make sense to explicitly state = that? >=20 > Good point. That section is mostly talking about the client, I'll add = a section for the server. I agree, the normal behavior would not be to = revoke previously granted scopes (which is how Google implements it). >=20 > Best, > William >=20 >=20 > > Am 28.06.2018 um 22:14 schrieb internet-drafts@ietf.org: > >=20 > >=20 > > 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. > >=20 > > Title : OAuth 2.0 Incremental Authorization > > Author : William Denniss > > Filename : draft-ietf-oauth-incremental-authz-00.txt > > Pages : 8 > > Date : 2018-06-28 > >=20 > > Abstract: > > OAuth 2.0 authorization requests that include every scope the = client > > might ever need can result in over-scoped authorization and a sub- > > optimal end-user consent experience. This specification enhances = the > > OAuth 2.0 authorization protocol by adding incremental = authorization, > > the ability to request specific authorization scopes as needed, = when > > they're needed, removing the requirement to request every possible > > scope that might be needed upfront. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ > >=20 > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-00 > > = https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-authz-0= 0 > >=20 > >=20 > > 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. > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_BDFB3C57-BF63-418B-BF85-0E38982C4E24 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNzE3MjAyNjU3WjAjBgkqhkiG9w0BCQQxFgQURPlTdPVfUQEt yWqEqQ3w07HS6A0wgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAE2GoWNz2LF8pRJG6fq8bV5WqmHQIgf3FhNq+3kgRwrvoR83kCft 1CDke0ijyqJL2ucnemw7AII11WSEARGEg99UVg2sumv9G/Ea5amNChbKVkxAj9O/c7G3RTe+6+0x cbmxg4xfThATr3JJiesumhTHjI+G7xCtb5X7SQltReIuVWBkBHmpOTxGXW9xaWccxVf5V1mIaslJ r6sRXqKiWwJIaDEJWIWDQjpe5QhBXZM/JC83kbHG5+uEIV3dT0UV1/+S7Omr4/FT76IsvivsnG2X VJSTCkt1QGVGXor/uwpCRUzcLndedhRQOwA+igeC4UL04MlNWLnehPz+VeANNA4AAAAAAAA= --Apple-Mail=_BDFB3C57-BF63-418B-BF85-0E38982C4E24-- From nobody Tue Jul 17 15:42:33 2018 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 5944D130E1E; Tue, 17 Jul 2018 15:42:24 -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.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <153186734430.12667.18074816487124272831@ietfa.amsl.com> Date: Tue, 17 Jul 2018 15:42:24 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 22:42:25 -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 Flow for Browserless and Input Constrained Devices Authors : William Denniss John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-11.txt Pages : 19 Date : 2018-07-17 Abstract: 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. 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-11 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 Tue Jul 17 15:45:56 2018 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 ECA1F130DF4 for ; Tue, 17 Jul 2018 15:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 N3cgIroCv2Rq for ; Tue, 17 Jul 2018 15:45:52 -0700 (PDT) Received: from mail-ua0-x243.google.com (mail-ua0-x243.google.com [IPv6:2607:f8b0:400c:c08::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 3802F130F1D for ; Tue, 17 Jul 2018 15:45:52 -0700 (PDT) Received: by mail-ua0-x243.google.com with SMTP id g18-v6so1729281uam.6 for ; Tue, 17 Jul 2018 15:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xJuiTb+gLNHPRLyEcqSrBqJ5mAG8TpIOxziuj0k1Zbg=; b=uWEQFBrRSPhp775aoR4s/B2fDsriioSLc+7gxwtggqiezBE9PxfjddQ186xbLGLqQy bepcMbcvL4TPxJJ0xkwoN3Mtu2Pf6BHHMG2q2XZz8xy7D3JdiZ9nZ+3Rgqao7XSif8Yc 8A2OZKO/yNCl1RDBaUqUBM5yBbmU3MS2YxQDw8pVwCpcbSSaQ6SJxi5EhFldaXmRM7sz aWecW5KLnRFWbQGv38nlZypanTiDUVl+Ii4IyVf4N9jr+Imzc+5mjTQRb62mI9vUXVU1 qTRpf5r0Ybfu/do6KJYhtEfJ8HJJasadC1VldEGCs9HSNJ3WTob88gNuQHn9JZxERb5W 7XfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xJuiTb+gLNHPRLyEcqSrBqJ5mAG8TpIOxziuj0k1Zbg=; b=SqFiUU4Uq4AWnivgRAnVCnZS+DLGqioz4Fx1v2PU6vHjVgHaRD3WoVGVyvzc7WQv3g 3BB0LNN1s0tx/o5Wik7yc1sqry3GGeaBP8/cDd/KYO/rHd3GzckR53PTpSAF2AbecpN6 4fPYgqCLM2X9AQhTjDcK1FIeN2gLjOMU1CX9vFEG6Fl1jGaU3RavekACJx6faPzjhV7X V9DbQFF7P6JHQNY0sD8ZNd9wSTO5dlb3vBlkWh3LiZTsExVPWZ+9Ga/vnTZKhAlEkMlD bwHLcXpjo/k88wvzpfjKPeTKMNKqjxqBYi20U/oEI2EQ+B+Sq73deUhKBVCis5CT3ToC Wz3Q== X-Gm-Message-State: AOUpUlERuIERZ9RcNPqN+3Hc/W6beDD1Mof4rXb9bJb5zrs0osbBQ9hh 3kF+Y7NVeMtvCzqQjfpAI/RZ8DnCNVwEgL7eBCf+8ROe+IQ= X-Google-Smtp-Source: AAOMgpcnSh+A7h1gvwTVp2HkRZa7q/c8nbEc/uKy43pRNfRkoHBCDgdiD8OQ0Or4YJUesL0Za5/ZuejinMzKwYBruSg= X-Received: by 2002:ab0:2783:: with SMTP id t3-v6mr2358875uap.181.1531867550662; Tue, 17 Jul 2018 15:45:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:6383:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 15:45:30 -0700 (PDT) In-Reply-To: <153186734430.12667.18074816487124272831@ietfa.amsl.com> References: <153186734430.12667.18074816487124272831@ietfa.amsl.com> From: William Denniss Date: Tue, 17 Jul 2018 15:45:30 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000033c014057139b5fe" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 22:45:55 -0000 --00000000000033c014057139b5fe Content-Type: text/plain; charset="UTF-8" Version 11 updates the reference to the published version of OAuth 2.0 Authorization Server Metadata (RFC 8414). On Tue, Jul 17, 2018 at 3:42 PM, wrote: > > 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 Flow for Browserless and Input > Constrained Devices > Authors : William Denniss > John Bradley > Michael B. Jones > Hannes Tschofenig > Filename : draft-ietf-oauth-device-flow-11.txt > Pages : 19 > Date : 2018-07-17 > > Abstract: > 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. > > > 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-11 > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-11 > > > 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/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000033c014057139b5fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Version 11 updates the reference to the published version = of=C2=A0OAuth 2.0 Authorization Server Metadata (RFC 8414).

=
On Tue, Jul 17, 2018 at 3:42 PM, <inter= net-drafts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Will= iam Denniss
=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 John Bradley
=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 Michael B. Jones
=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 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-device-flow-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-07-17

Abstract:
=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input =C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena= bles
=C2=A0 =C2=A0OAuth clients to request user authorization from devices that = have an
=C2=A0 =C2=A0Internet connection, but don't have an easy input method (= such as a
=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=
=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=
=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza= tion
=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The= re is no
=C2=A0 =C2=A0requirement for communication between the constrained device a= nd the
=C2=A0 =C2=A0user's secondary device.


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-ie= tf-oauth-device-flow-11
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-device-flow-11


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

--00000000000033c014057139b5fe-- From nobody Wed Jul 18 06:32:30 2018 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 F2217130E9A for ; Wed, 18 Jul 2018 06:32:28 -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 CB5giYCOWNdA for ; Wed, 18 Jul 2018 06:32:27 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 15E45130DE5 for ; Wed, 18 Jul 2018 06:32:27 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 126-v6so723727qke.5 for ; Wed, 18 Jul 2018 06:32:27 -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=gMKESGf1WKBmUETsXzbJq+RUBkXgP+w4WXcQZtTthoE=; b=vDlAgHZ2nAplAAadxjirKuv7YskckP0mj6eJPqJves5sBMNOxcgGS9VlV0hxEz1hVd ApX4fUtMg6dV3Cgowd/RApv2Q/uXkJjpbatsjhaI9IVenMcKK0PiTzy44iatxzVT7Osd BaFcMulyShydUKSjLQLJIn2wOTM0XvFpHU1nrl3vNfzYepznyJImKzFdq0ACIsQM63hv KOCV6oC4F2FeDA/F3A+j0/0y5OOsh4OCXKyTjyuJvChHt7VLysce/5+tEQ3wmohdmjNX DzAqXJaR9hx9TN98m0+96LouszNkhU8waRW0rXvZZXlA0mx/H6ZC3JX8T0WklX5LpiC9 nsrA== 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=gMKESGf1WKBmUETsXzbJq+RUBkXgP+w4WXcQZtTthoE=; b=ZIm3UqoVY+jf1Qs+n24pNqaTT3jnyc8QVHj9belS///IEUlNyBY4OI6pEuuS1/y18U 31hbsBWwphByYoteIePR3xk+18RWMMd/i/SBoIXfPvJ8bNWP34UTo/Q0PoJ9tOJgPtiV SUeLK5ObSVne4/WG3RZ43E1dXZ6P0Dg5D/LcNEAXO4b4KL+32RpyXnIEXmNymIbX4Y0o mwcZV1FpCWBEYeVzVztjnTonOmadgwA42a67ayK4FTfObsR3fbivMz63pKGICq4Oi0Pw ykoIx1Ppn54Mib5GmDmYBsf8JDJ8Uhlgh2P40f2DZsb0pW5+V6yDlWfqXSCArOzT0Qjv E9jA== X-Gm-Message-State: AOUpUlFSJ9LGiz9upsCLRWWZw5RGfm+VZalz6GxIPJEj92ELjvGUhodv /cCFadM0Kdw3ygVYnxDFrY/74cnjgRAqE3VVVzkKjw== X-Google-Smtp-Source: AAOMgpdOIGd9f+E3iJp8y/IHrfzH0ilKWwfcO+FgnO9XfDdBlBHsQ6JTgilXdMdlwQBEYqHaGVQsQwWT3YCJiIwrQcE= X-Received: by 2002:a37:34cb:: with SMTP id b194-v6mr5399021qka.258.1531920745806; Wed, 18 Jul 2018 06:32:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:4112:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 06:32:25 -0700 (PDT) From: Kaoru Maeda Date: Wed, 18 Jul 2018 09:32:25 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e0bec8057146171d" Archived-At: Subject: [OAUTH-WG] Editorial: draft-ietf-oauth-jwsreq-16 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 13:32:29 -0000 --000000000000e0bec8057146171d Content-Type: text/plain; charset="UTF-8" Hi, I have some questions on jwsreq-16 (maybe editorial). * Section 5.2.1 In the request_uri example, what does fragment part (#Gku...) mean? https://tfp.example.org/request.jwt#GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM Does this fragment correspond to the entropy mentioned in the text? * Section 10.4 "redirect_uri" should read "request_uri" * Section 10.4.x There are two media types mentioned: application/jose, and /json. Earlier in the document I found application/jwt. It seems to make sense even when all of these are application/jwt. Does application/jose specifically mean JWS/JWE? Is these difference intentional? Regards, Kaoru Maeda --000000000000e0bec8057146171d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have some questions on jwsreq-16 = (maybe editorial).

* Section 5.2.1
In th= e request_uri example, what does fragment part (#Gku...) mean?
Does this fragment correspond = to the entropy mentioned in the text?

* Section 10= .4
"redirect_uri" should read "request_uri"

* Section 10.4.x
There are two media type= s mentioned: application/jose, and /json.
Earlier in the document= I found application/jwt.
It seems to make sense even when all of= these are application/jwt.
Does application/jose specifically me= an JWS/JWE?
Is these difference intentional?

=
Regards,

Kaoru Maeda=C2=A0
--000000000000e0bec8057146171d-- From nobody Thu Jul 19 00:55:02 2018 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 C7B3B130E97 for ; Thu, 19 Jul 2018 00:55:00 -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, 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 AAMVRPwZJaLQ for ; Thu, 19 Jul 2018 00:54:57 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6505F130E93 for ; Thu, 19 Jul 2018 00:54:57 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:cc43:fa13:59a2:45be] (unknown [IPv6:2601:282:202:b210:cc43:fa13:59a2:45be]) by alkaline-solutions.com (Postfix) with ESMTPSA id E020E315EC; Thu, 19 Jul 2018 07:54:55 +0000 (UTC) From: David Waite Message-Id: <1AD25F21-4F76-41CA-96E8-6E09373D04E8@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1795FE5B-7170-4530-993F-5A7E0DF82EFC" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 19 Jul 2018 01:54:54 -0600 In-Reply-To: Cc: oauth@ietf.org To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 07:55:01 -0000 --Apple-Mail=_1795FE5B-7170-4530-993F-5A7E0DF82EFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Four comments. First: What is the rationale for including the parameters as Link = headers rather than part of the WWW-Authenticate challenge, e.g.: WWW-Authenticate: Bearer realm=3D"example_realm", scope=3D"example_scope", error=3D=E2=80=9Cinvalid_token", resource_uri=3D"https://api.example.com/resource", = oauth_server_metadata_uris=3D"https://as.example.com/.well-known/oauth-aut= horization-server = https://different-as.example.com/.well-known/oauth-authorization-server" My understanding is that the RFC6750 auth-params are extensible (but not = currently part of any managed registry.) One reason to go with this vs Link headers is CORS policy - exposing = Link headers to a remote client must be done all or nothing as part of = the CORS policy, and can=E2=80=99t be limited by the kind of link. Second: (retaining link format) Is there a reason the metadata location = is specified the way it is? It seems like ; = rel=3D=E2=80=9Coauth_server_metadata_uri" should be ; rel=3D=E2=80=9Coauth_issuer" OAuth defines the location of metadata under the .well-known endpoint as = a MUST. An extension of OAuth may choose from at least three different = methods for handling extensions beyond this: 1. Add additional keys to the oauth-authorization-server metadata 2. Add additional resources to .well-known for clients to supporting = their extensions to attempt to resolve, treating =E2=80=98regular=E2=80=99= OAuth as a fallback. 3. Define their own parameter, such as rel=3D=E2=80=9Cspecialauth_issuer=E2= =80=9D, potentially using a different mechanism for specifying metadata Given all this, it seems appropriate to only support specifying of = metadata-supplying issuers, not metadata uris. Third: I have doubts of the usefulness of resource_uri in parallel to = both the client requested URI and the Authorization =E2=80=9Crealm=E2=80=9D= parameter. As currently defined, the client would be the one enforcing (or possibly = ignoring) static policy around resource URIs - that a resource URI is = arbitrary except in that it must match the host (and scheme/port?) of = the requested URI. The information on the requested URI by the client is = not shared between the client and AS for it to do its own policy = verification. It would seem better to send the client origin to the AS = for it to do (potential) policy verification, rather than relying on = clients to implement it for them based on static spec policy. The name =E2=80=9Cresource URI=E2=80=9D is also confusing, as I would = expect it to be the URI that was requested by the client. The purpose of = this parameter is a bit confusing, as it is only defined as =E2=80=9CAn = OAuth 2.0 Resource Endpoint specified in [RFC6750] section 3.2 - where = the term doesn=E2=80=99t appear in 6750 and there does not appear to be = a section 3.2 ;-) It seems that: a. If the resource_uri is a direct match for the URI requested for the = client, it is redundant and should be dropped (If the resource URI is *not* a direct match with the URI of the = resource requested by the client, it might need a better name). b. If the resource URI is meant to provide a certain arbitrary grouping = for applying tokens within the origin of the resource server, what is = its value over the preexisting =E2=80=9C realm=E2=80=9D parameter? c. If the resource URI is meant to provide a way for an AS to allow = resources to be independent, identified entities on a single origin - = I=E2=80=99m unsure how a client would understand it is meant to treat = these resource URIs as independent entities (e.g. be sure not to send = bearer tokens minted for resource /entity1 to /entity2, or for that = matter prevent /entity1 from requesting tokens for /entity2). Admittedly based on not fully understanding the purpose of this = parameter, it seems to me there exists a simpler flow which better = leverages the existing Authentication mechanism of HTTP.=20 A request would fail due to an invalid or missing token for the realm at = the origin, and and the client would make a request to the issuer = including the origin of the requested resource as a parameter. Any other = included parameters specified by the WWW-Authenticate challenge = understood by the client (such as =E2=80=9Cscope=E2=80=9D) would also be = applied to this request. Normal authorization grant flow would then happen (as this is the only = grant type supported by RFC6750). Once the access token is acquired by = the client, the client associates that token with the =E2=80=9Crealm=E2=80= =9D parameter given in the initial challenge by the resource server = origin. Likewise, the =E2=80=98aud=E2=80=99 of the token as returned by = a token introspection process would be the origin of the resource = server. It seems any more complicated protected resource groupings on a resource = server would need a client to understand the structure of the resource = server, and thus fetch some sort of resource server metadata. Fourth and finally: Is the intention to eventually recommend token = binding here? Token binding as a requirement across clients, resources, = and the authorization servers would isolate tokens to only being = consumed within an origin. This would actually make = redundant/supplemental the AS additions defined within this spec = (resource/origin request parameter, =E2=80=98aud=E2=80=99 introspection = response member) -DW > On Jun 12, 2018, at 1:28 PM, Dick Hardt wrote: >=20 > Hey OAuth WG >=20 > I have worked with Nat and Brian to merge our concepts and those are = captured in the updated draft. >=20 > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ = >=20 > We are hopeful the WG will adopt this draft as a WG document. >=20 > Any comments and feedback are welcome! >=20 > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1795FE5B-7170-4530-993F-5A7E0DF82EFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Four = comments.

First: = What is the rationale for including the parameters as Link headers = rather than part of the WWW-Authenticate challenge, e.g.:

WWW-Authenticate: Bearer = realm=3D"example_realm",
      =                     =    scope=3D"example_scope",
    =                     =      error=3D=E2=80=9Cinvalid_token",
    resource_uri=3D"https://api.example.com/resource",
    oauth_server_metadata_uris=3D"https://as.example.com/.well-known/oauth-authorization-server https://different-as.example.com/.well-known/oauth-authorizatio= n-server"


My = understanding is that the RFC6750 auth-params are extensible (but not = currently part of any managed registry.)

One reason to go with = this vs Link headers is CORS policy - exposing Link headers to a remote = client must be done all or nothing as part of the CORS policy, and = can=E2=80=99t be limited by the kind of link.

Second: (retaining link format) Is = there a reason the metadata location is specified the way it is? It = seems like

<https://as.example.com/.well-known/oauth-authorization-server>; rel=3D=E2=80=9Coauth_server_metadata_uri"
should be

<https://as.example.com>;= rel=3D=E2=80=9Coauth_issuer"

OAuth defines the location of metadata = under the .well-known endpoint as a MUST. An extension of OAuth may = choose from at least three different methods for handling extensions = beyond this:
1. Add additional keys to the = oauth-authorization-server metadata
2. Add = additional resources to .well-known for clients to supporting their = extensions to attempt to resolve, treating =E2=80=98regular=E2=80=99 = OAuth as a fallback.
3. Define their own parameter, = such as rel=3D=E2=80=9Cspecialauth_issuer=E2=80=9D, potentially using a = different mechanism for specifying metadata

Given all this, it seems appropriate to = only support specifying of metadata-supplying issuers, not metadata = uris.

Third: I = have doubts of the usefulness of resource_uri in parallel to both the = client requested URI and the Authorization =E2=80=9Crealm=E2=80=9D = parameter.

As currently defined, the client would be the one enforcing = (or possibly ignoring) static policy around resource URIs - that a = resource URI is arbitrary except in that it must match the host (and = scheme/port?) of the requested URI. The information on the requested URI = by the client is not shared between the client and AS for it to do its = own policy verification. It would seem better to send the client origin = to the AS for it to do (potential) policy verification, rather than = relying on clients to implement it for them based on static spec = policy.

The = name =E2=80=9Cresource URI=E2=80=9D is also confusing, as I would expect = it to be the URI that was requested by the client. The purpose of this = parameter is a bit confusing, as it is only defined as =E2=80=9CAn OAuth = 2.0 Resource Endpoint specified in [RFC6750] section 3.2 - where the = term doesn=E2=80=99t appear in 6750 and there does not appear to be a = section 3.2 ;-)

It seems that:
a. If the resource_uri is = a direct match for the URI requested for the client, it is redundant and = should be dropped
    (If the resource = URI is *not* a direct match with the URI of the resource requested by = the client, it might need a better name).
b. If the = resource URI is meant to provide a certain arbitrary grouping for = applying tokens within the origin of the resource server, what is its = value over the preexisting =E2=80=9C realm=E2=80=9D = parameter?
c. If the resource URI is meant to = provide a way for an AS to allow resources to be independent, identified = entities on a single origin - I=E2=80=99m unsure how a client would = understand it is meant to treat these resource URIs as independent = entities (e.g. be sure not to send bearer tokens minted for resource = /entity1 to /entity2, or for that matter prevent /entity1 from = requesting tokens for /entity2).

Admittedly based on not fully understanding the = purpose of this parameter, it seems to me there exists a simpler flow = which better leverages the existing Authentication mechanism of = HTTP. 

A request would fail due = to an invalid or missing token for the realm at the origin, and and the = client would make a request to the issuer including the origin of the = requested resource as a parameter. Any other included parameters = specified by the WWW-Authenticate challenge understood by the = client (such as =E2=80=9Cscope=E2=80=9D) would also be applied to = this request.

Normal authorization = grant flow would then happen (as this is the only grant type supported = by RFC6750). Once the access token is acquired by the client, the client = associates that token with the =E2=80=9Crealm=E2=80=9D parameter given = in the initial challenge by the resource server origin. Likewise, the = =E2=80=98aud=E2=80=99 of the token as returned by a token introspection = process would be the origin of the resource server.

It seems any more complicated protected resource = groupings on a resource server would need a client to understand the = structure of the resource server, and thus fetch some sort of resource = server metadata.

Fourth and finally: = Is the intention to eventually recommend token binding here? Token = binding as a requirement across clients, resources, and the = authorization servers would isolate tokens to only being consumed within = an origin. This would actually make redundant/supplemental the AS = additions defined within this spec (resource/origin request parameter, = =E2=80=98aud=E2=80=99 introspection response member)

-DW

On Jun 12, 2018, at 1:28 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

Hey OAuth WG

I have worked with Nat and Brian to merge our concepts and = those are captured in the updated draft.

https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/=

We are hopeful the WG will adopt this draft as a WG = document.

Any = comments and feedback are welcome!

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

= --Apple-Mail=_1795FE5B-7170-4530-993F-5A7E0DF82EFC-- From nobody Thu Jul 19 05:52:00 2018 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 D09B6130E59 for ; Thu, 19 Jul 2018 05:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 atH1S3SKb63t for ; Thu, 19 Jul 2018 05:51:46 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.93]) (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 AC5F8129619 for ; Thu, 19 Jul 2018 05:51:46 -0700 (PDT) Received: from [91.14.23.243] (helo=[192.168.179.103]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fg8PH-0000dp-IG; Thu, 19 Jul 2018 14:51:43 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-8096C819-9693-4A75-AC82-B2D8C27BB346; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (15F79) In-Reply-To: Date: Thu, 19 Jul 2018 14:51:41 +0200 Cc: oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> References: To: Dick Hardt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 12:51:56 -0000 --Apple-Mail-8096C819-9693-4A75-AC82-B2D8C27BB346 Content-Type: multipart/alternative; boundary=Apple-Mail-588E3AA2-EB37-4FF8-A416-73E2DF324D49 Content-Transfer-Encoding: 7bit --Apple-Mail-588E3AA2-EB37-4FF8-A416-73E2DF324D49 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dick, > =20 >>=20 >> Section 3:=20 >> Don=E2=80=99t you think it could be a useful information to have the reso= urce URI available in the authorization flow?I would assume it could have so= me additional meaning to the AS and could also be the context of the scope. >=20 > I'm assuming you are referring to the Authorization Code Grant. Good call o= ut that the resource URI would be useful in the redirect.=20 >=20 > The use cases that I have been working with have all been Client Credentia= l Grants >=20 > I currently don't know of a real world use case for the Authorization Code= Grant for Distributed OAuth. I think any scenario with multiple resource servers relying on the same AS f= or authorization where the client acts on behalf of the resource owner quali= fies for grant type code and distributed OAuth.=20 Let=E2=80=99s assume a user wants to authorize a client for access to her cl= oud storage, email account and contacts when setting app the respective app.= One would use the code grant type for that use case. And having the resource= URLs in the authorization flow would allow the AS to further determine the c= ontext of the requested authorization. Even more important, the AS could restrict the access tokens for use at this= URIs only. At best, the AS would allow the client to obtain different acces= s tokens for any of the involved resource servers, each of them tailored to t= he needs of the particular RS (content) and bound to it (aud, token binding,= ...). In the YES context, we have several different services/resources, which can b= e combined in a single authorization transaction, e.g. initiation of a payme= nt and creating an electronic signature. In all solutions I have seen or designed in the past, the resource server wa= s either carried in the scope parameter or implicitly determined from the sc= ope values (see OIDC). Making it explicit would result in an interoperable a= pproach to represent this information and use it to tighten up OAuth securit= y and privacy (token binding, audience restriction). kind regards, Torsten. > =20 >>=20 >> Section 4:=20 >> I think the client MUST authenticate using a PoP (asymmetric crypto based= ) mechanisms due to the attack angle given in 6.3 >> Did you intentionally restricted the draft to single resources? >=20 > yes > =20 >> I would desire support for an integrated UI flow for authorizing access t= o multiple resources at once. This makes sense in multi-service deployments.= >=20 > It could be. Would be great to get some real use cases for that in an Auth= orization Code Grant. > =20 >>=20 >> Section 6.1.=20 >> I suggest you also refer to https://tools.ietf.org/html/draft-ietf-oauth-= security-topics-06#section-3.7 for a comprehensive discussion of this threat= . >=20 > Thanks > =20 >>=20 >> kind regards, >> Torsten. =20 >>=20 >>=20 >> > Am 12.06.2018 um 21:28 schrieb Dick Hardt : >> >=20 >> > Hey OAuth WG >> >=20 >> > I have worked with Nat and Brian to merge our concepts and those are ca= ptured in the updated draft. >> >=20 >> > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ >> >=20 >> > We are hopeful the WG will adopt this draft as a WG document. >> >=20 >> > Any comments and feedback are welcome! >> >=20 >> > /Dick >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail-588E3AA2-EB37-4FF8-A416-73E2DF324D49 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Dick,

 

Section 3:
Don=E2=80=99t you think it could be a useful information to have the resourc= e URI available in the authorization flow?I would assume it could have some a= dditional meaning to the AS and could also be the context of the scope.
<= /blockquote>

I'm assuming you are referring to the Author= ization Code Grant. Good call out that the resource URI would be useful in t= he redirect. 

The use cases that I have been w= orking with have all been Client Credential Grants

= I currently don't know of a real world use case for the Authorization Code G= rant for Distributed OAuth.
<= br>
I think any scenario with multiple resource servers relying on the s= ame AS for authorization where the client acts on behalf of the resource own= er qualifies for grant type code and distributed OAuth. 

=
Let=E2=80=99s assume a user wants to authorize a client for access to h= er cloud storage, email account and contacts when setting app the respective= app.

One would use the code grant type for that use case= . And having the resource URLs in the authorization flow would allow the AS t= o further determine the context of the requested authorization.
Even more important, the AS could restrict the access tokens fo= r use at this URIs only. At best, the AS would allow the client to obtain di= fferent access tokens for any of the involved resource servers, each of them= tailored to the needs of the particular RS (content) and bound to it (aud, t= oken binding, ...).

In the YES context, we have sev= eral different services/resources, which can be combined in a single authori= zation transaction, e.g. initiation of a payment and creating an electronic s= ignature.

In all solutions I have seen or designed i= n the past, the resource server was either carried in the scope parameter or= implicitly determined from the scope values (see OIDC). Making it explicit w= ould result in an interoperable approach to represent this information and u= se it to tighten up OAuth security and privacy (token binding, audience rest= riction).

kind regards,
Torsten.

 

Section 4:
I think the client MUST authenticate using a PoP (asymmetric crypto based) m= echanisms due to the attack angle given in 6.3
Did you intentionally restricted the draft to single resources?

yes
 
I would desire support for an integrated UI flow for authorizing access to m= ultiple resources at once. This makes sense in multi-service deployments.

It could be. Would be great to get some re= al use cases for that in an Authorization Code Grant.
 
=

Section 6.1.
I suggest you also refer to https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06#s= ection-3.7 for a comprehensive discussion of this threat.

Thanks
 

kind regards,
Torsten.   


> Am 12.06.2018 um 21:28 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Hey OAuth WG
>
> I have worked with Nat and Brian to merge our concepts and those are ca= ptured in the updated draft.
>
> https://datatracker.ietf.org/= doc/draft-hardt-oauth-distributed/
>
> We are hopeful the WG will adopt this draft as a WG document.
>
> Any comments and feedback are welcome!
>
> /Dick
> ___________________= ____________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail-588E3AA2-EB37-4FF8-A416-73E2DF324D49-- --Apple-Mail-8096C819-9693-4A75-AC82-B2D8C27BB346 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcxOTEyNTE0MVow IwYJKoZIhvcNAQkEMRYEFLrpX0ZLoKO0LxiyoLeBIQgu9yQcMIG+BgkrBgEEAYI3EAQxgbAwga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQC0vJmusgkMxs0Y26TD AaPLUEOEiEHdPhdYtmldoapEkkx4tMvOi71HQTGaO1gvpEg/kiaDyv0tE/Rv0YOhUSp7doTaxM+L ZTMKbOxGOROVYXPIFK99XWkcH0POXytAFrOy6oCtmdHuKWzzZlSgWoWlbolG/ESUtaWpuYH7AMGj oFRKJJGxyh4mS4j2ayRVF4pXXmNGD2on+Pzy9HhNTjlGKk7fgubATh/jkqX3kQjDPUUualn+1/OT 6Sw7wNc05o8DMC6TI5FwCECt2tlkfPEdAFtDFlTFZAAX6r/KELkThtvH2YYRv1zW7Z0cCNGOGECt fiuhW2wDMbqrL1huysxTAAAAAAAA --Apple-Mail-8096C819-9693-4A75-AC82-B2D8C27BB346-- From nobody Thu Jul 19 06:42:39 2018 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 8EDE0130E29 for ; Thu, 19 Jul 2018 06:42:37 -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 ksTtyqyqQN4v for ; Thu, 19 Jul 2018 06:42:34 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 BE801130E0D for ; Thu, 19 Jul 2018 06:42:34 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id n7-v6so3809589pgq.4 for ; Thu, 19 Jul 2018 06:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hxM4cMXhK9flqvJA9J4U3+kdwDL47jQkJ3K2j36CNQY=; b=aJyzkVxWqFh45P8wMfE2C3Yxj3tHpTh7LbI94Wk/HG+Um4hYVO8ICpVLmhrFU5AT0K cBvmZpngUqre8PDizwiz1H2KBvQ8+R4qxcttMmYiBMwrcaCoDtmOW9QFbSWgB7QsFRxe ezXTBb3VIWALxeeDdgtstYMwEzKGGICJjTz4vqDFP96m1wCAxrJCy1TAVVwdwHl+XjGj y9JhiITydHRPQLw/kbGKKw/zhW+SZaBc9aMf4heWblLbir4sFoafiMnckg8mrWAJ7MVS hQMbhgqLoVPLm1vkuWPefg21sdJnIVWFLmoGmnzrNOvKRafY/lzjK0Z99geHvHCTZgNN 6zIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hxM4cMXhK9flqvJA9J4U3+kdwDL47jQkJ3K2j36CNQY=; b=iI21aszTiYtwk6ODU6C04VOw++3MrfVeb/x85RWCFFLoxXNqB8jqtjXLtA/ZmI52ap ISsGWLzMCo86rbJTsChlQuTbJYEUgI1epm3nBM4UFyIx3XCVHTmYp/2bHjQTg3RvVUN0 vKt8iWcRrNIxKHKTkuJZqJ5uJF9IAMhtUc9gAt1ur+HusPpksFTt04Yx8scswoq1aJOu pUng+V7IJM2hAflgQWpLZ5V7dsOHAJoDmmJ3vZtWfQVf3lkaNk/G/LhVCBP8BqUAWR7B oMESlX1hPU30l3aJwpN41iRLJ9ree297VYYM7QFnBPj926dJV8CrmTA89hUwZHkrTBzP 7Ixg== X-Gm-Message-State: AOUpUlG8lvQh1epB8iOttJzcNZ4GL6rlrXhvg2OI/ips2xjQRNr8A1ih TtJQRMtOp+POq1fTpdZamhAtR1/93SSmpvTm1o2iAa4Y X-Google-Smtp-Source: AAOMgpf1mBZPhHsg39h7pHFeX6qkOhQ27mFPqmlW+pzj3mFR+YC4ESiC+ezGhAKgNBC2LUV6tDOiyy3tLDYMh/VOL3s= X-Received: by 2002:a62:be03:: with SMTP id l3-v6mr9572250pff.138.1532007754185; Thu, 19 Jul 2018 06:42:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Thu, 19 Jul 2018 06:42:13 -0700 (PDT) In-Reply-To: <1AD25F21-4F76-41CA-96E8-6E09373D04E8@alkaline-solutions.com> References: <1AD25F21-4F76-41CA-96E8-6E09373D04E8@alkaline-solutions.com> From: Dick Hardt Date: Thu, 19 Jul 2018 09:42:13 -0400 Message-ID: To: David Waite Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000fb41d205715a599a" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 13:42:38 -0000 --000000000000fb41d205715a599a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable David, thanks for the detailed feedback ... responses inline ... On Thu, Jul 19, 2018 at 3:54 AM, David Waite wrote: > Four comments. > > First: What is the rationale for including the parameters as Link headers > rather than part of the WWW-Authenticate challenge, e.g.: > > WWW-Authenticate: Bearer realm=3D"example_realm", > scope=3D"example_scope", > error=3D=E2=80=9Cinvalid_token", > resource_uri=3D"https://api.example.com/resource", > oauth_server_metadata_uris=3D"https://as.example.com/.well- > known/oauth-authorization-server https://different-as.example. > com/.well-known/oauth-authorization-server" > > > My understanding is that the RFC6750 auth-params are extensible (but not > currently part of any managed registry.) > > One reason to go with this vs Link headers is CORS policy - exposing Link > headers to a remote client must be done all or nothing as part of the COR= S > policy, and can=E2=80=99t be limited by the kind of link. > > Nat had a good argument for using Link headers, I'll let him respond. > Second: (retaining link format) Is there a reason the metadata location i= s > specified the way it is? It seems like > > ; > rel=3D=E2=80=9Coauth_server_metadata_uri" > > should be > > ; rel=3D=E2=80=9Coauth_issuer" > > OAuth defines the location of metadata under the .well-known endpoint as = a > MUST. An extension of OAuth may choose from at least three different > methods for handling extensions beyond this: > 1. Add additional keys to the oauth-authorization-server metadata > 2. Add additional resources to .well-known for clients to supporting thei= r > extensions to attempt to resolve, treating =E2=80=98regular=E2=80=99 OAut= h as a fallback. > 3. Define their own parameter, such as rel=3D=E2=80=9Cspecialauth_issuer= =E2=80=9D, > potentially using a different mechanism for specifying metadata > > Given all this, it seems appropriate to only support specifying of > metadata-supplying issuers, not metadata uris. > Interesting, what do others think of this? There is a security advantage of using a predefined path as a malicious RS can not have the client fetch a different meta data document than the one that is at the well known location. > > Third: I have doubts of the usefulness of resource_uri in parallel to bot= h > the client requested URI and the Authorization =E2=80=9Crealm=E2=80=9D pa= rameter. > > As currently defined, the client would be the one enforcing (or possibly > ignoring) static policy around resource URIs - that a resource URI is > arbitrary except in that it must match the host (and scheme/port?) of the > requested URI. The information on the requested URI by the client is not > shared between the client and AS for it to do its own policy verification= . > It would seem better to send the client origin to the AS for it to do > (potential) policy verification, rather than relying on clients to > implement it for them based on static spec policy. > > The name =E2=80=9Cresource URI=E2=80=9D is also confusing, as I would exp= ect it to be the > URI that was requested by the client. The purpose of this parameter is a > bit confusing, as it is only defined as =E2=80=9CAn OAuth 2.0 Resource En= dpoint > specified in [RFC6750] section 3.2 - where the term doesn=E2=80=99t appea= r in 6750 > and there does not appear to be a section 3.2 ;-) > > It seems that: > a. If the resource_uri is a direct match for the URI requested for the > client, it is redundant and should be dropped > (If the resource URI is *not* a direct match with the URI of the > resource requested by the client, it might need a better name). > It is not a direct match. Open to new name suggestions! > b. If the resource URI is meant to provide a certain arbitrary grouping > for applying tokens within the origin of the resource server, what is its > value over the preexisting =E2=80=9C realm=E2=80=9D parameter? > It is not arbitrary. The resource URI MUST be contained in the URI the client is requesting access to. The hostname in the resource URI must be in the hostname in the TLS certificate. This lets the client ensure it is requesting an access token that is intended for the resource it is accessing. The realm parameter does not have these characteristics specified, and may already be used for other purposes. > c. If the resource URI is meant to provide a way for an AS to allow > resources to be independent, identified entities on a single origin - I= =E2=80=99m > unsure how a client would understand it is meant to treat these resource > URIs as independent entities (e.g. be sure not to send bearer tokens mint= ed > for resource /entity1 to /entity2, or for that matter prevent /entity1 fr= om > requesting tokens for /entity2). > It is intended for the client to enforce. > > Admittedly based on not fully understanding the purpose of this parameter= , > it seems to me there exists a simpler flow which better leverages the > existing Authentication mechanism of HTTP. > > A request would fail due to an invalid or missing token for the realm at > the origin, and and the client would make a request to the issuer includi= ng > the origin of the requested resource as a parameter. Any other included > parameters specified by the WWW-Authenticate challenge understood by the > client (such as =E2=80=9Cscope=E2=80=9D) would also be applied to this re= quest. > > Normal authorization grant flow would then happen (as this is the only > grant type supported by RFC6750). Once the access token is acquired by th= e > client, the client associates that token with the =E2=80=9Crealm=E2=80=9D= parameter given > in the initial challenge by the resource server origin. Likewise, the =E2= =80=98aud=E2=80=99 > of the token as returned by a token introspection process would be the > origin of the resource server. > > It seems any more complicated protected resource groupings on a resource > server would need a client to understand the structure of the resource > server, and thus fetch some sort of resource server metadata. > I'm not understanding why you think this. Would you elaborate? > > Fourth and finally: Is the intention to eventually recommend token bindin= g > here? Token binding as a requirement across clients, resources, and the > authorization servers would isolate tokens to only being consumed within = an > origin. This would actually make redundant/supplemental the AS additions > defined within this spec (resource/origin request parameter, =E2=80=98aud= =E2=80=99 > introspection response member) > Token binding solves part of the resource constrained access token requirement, but does not solve how the client authenticates to the AS. > > -DW > > On Jun 12, 2018, at 1:28 PM, Dick Hardt wrote: > > Hey OAuth WG > > I have worked with Nat and Brian to merge our concepts and those are > captured in the updated draft. > > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ > > We are hopeful the WG will adopt this draft as a WG document. > > Any comments and feedback are welcome! > > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --000000000000fb41d205715a599a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
David, thanks for the detailed feedback ... responses inli= ne ...=C2=A0

On Th= u, Jul 19, 2018 at 3:54 AM, David Waite <david@alkaline-solutio= ns.com> wrote:
Four comments.
<= br>
First: What is the rationale for including the parameters as = Link headers rather than part of the WWW-Authenticate challenge, e.g.:

WWW-Authenticate: Bearer realm=3D"example_realm",<= /div>
=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=A0scope=3D"example_scope",=
=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=A0error=3D=E2=80=9Cinvalid_token&quo= t;,
=C2=A0 =C2=A0 resource_uri=3D"https://api.example.com/resource<= /a>",


=
My understanding is that the RFC6750 auth-params are extensible = (but not currently part of any managed registry.)

=
One reason to go with this vs Link headers is CORS policy - exposing L= ink headers to a remote client must be done all or nothing as part of the C= ORS policy, and can=E2=80=99t be limited by the kind of link.

Nat had a good argument= for using Link headers, I'll let him respond.
=C2=A0
Second: (retaining link format) Is = there a reason the metadata location is specified the way it is? It seems l= ike

<https://as.example.com/.w= ell-known/oauth-authorization-server>; rel=3D=E2=80=9Coaut= h_server_metadata_uri"

should be

<https://as.example.com>; rel=3D=E2=80=9Coauth_issuer"

OAuth defines the location of metadata under the= .well-known endpoint as a MUST. An extension of OAuth may choose from at l= east three different methods for handling extensions beyond this:
1. Add additional keys to the oauth-authorization-server metadata
2. Add additional resources to .well-known for clients to supporting thei= r extensions to attempt to resolve, treating =E2=80=98regular=E2=80=99 OAut= h as a fallback.
3. Define their own parameter, such as rel=3D=E2= =80=9Cspecialauth_issuer=E2=80=9D, potentially using a different mechanism = for specifying metadata

Given all this, it seems a= ppropriate to only support specifying of metadata-supplying issuers, not me= tadata uris.

Interesting,= what do others think of this?

There is a security= advantage of using a predefined path as a malicious RS can not have the cl= ient fetch a different meta data document than the one that is at the well = known location.
=C2=A0

Third: I have doubts of the usefulness of resource_uri in parallel= to both the client requested URI and the Authorization =E2=80=9Crealm=E2= =80=9D parameter.

As currently defined, the = client would be the one enforcing (or possibly ignoring) static policy arou= nd resource URIs - that a resource URI is arbitrary except in that it must = match the host (and scheme/port?) of the requested URI. The information on = the requested URI by the client is not shared between the client and AS for= it to do its own policy verification. It would seem better to send the cli= ent origin to the AS for it to do (potential) policy verification, rather t= han relying on clients to implement it for them based on static spec policy= .

The name =E2=80=9Cresource URI=E2=80=9D is also = confusing, as I would expect it to be the URI that was requested by the cli= ent. The purpose of this parameter is a bit confusing, as it is only define= d as =E2=80=9CAn OAuth 2.0 Resource Endpoint specified in [RFC6750] section= 3.2 - where the term doesn=E2=80=99t appear in 6750 and there does not app= ear to be a section 3.2 ;-)

It seems that:
a. If the resource_uri is a direct match for the URI requested for the c= lient, it is redundant and should be dropped
=C2=A0 =C2=A0 (If th= e resource URI is *not* a direct match with the URI of the resource request= ed by the client, it might need a better name).

It is not a direct match. Open to new name suggestions!
=C2=A0
b. If the resource URI is mea= nt to provide a certain arbitrary grouping for applying tokens within the o= rigin of the resource server, what is its value over the preexisting =E2=80= =9C=C2=A0realm=E2=80=9D parameter?

<= div>It is not arbitrary. The resource URI MUST be contained in the URI the = client is requesting access to. The hostname in the resource URI must be in= the hostname in the TLS certificate. This lets the client ensure it is req= uesting an access token that is intended for the resource it is accessing.<= /div>

The realm parameter does not have these characteri= stics specified, and may already be used for other purposes.
=C2= =A0
c. If the resource URI is meant to provi= de a way for an AS to allow resources to be independent, identified entitie= s on a single origin - I=E2=80=99m unsure how a client would understand it = is meant to treat these resource URIs as independent entities (e.g. be sure= not to send bearer tokens minted for resource /entity1 to /entity2, or for= that matter prevent /entity1 from requesting tokens for /entity2).

It is intended for the client to enfor= ce.
=C2=A0

Adm= ittedly based on not fully understanding the purpose of this parameter, it = seems to me there exists a simpler flow which better leverages the existing= Authentication mechanism of HTTP.=C2=A0

A request= would fail due to an invalid or missing token for the realm at the origin,= and and the client would make a request to the issuer including the origin= of the requested resource as a parameter. Any other included parameters sp= ecified by the WWW-Authenticate challenge understood by the client=C2=A0(su= ch as =E2=80=9Cscope=E2=80=9D) would also be applied to this request.
=

Normal authorization grant flow would then happen (as t= his is the only grant type supported by RFC6750). Once the access token is = acquired by the client, the client associates that token with the =E2=80=9C= realm=E2=80=9D parameter given in the initial challenge by the resource ser= ver origin. Likewise, the =E2=80=98aud=E2=80=99 of the token as returned by= a token introspection process would be the origin of the resource server.<= /div>

It seems any more complicated protected resource g= roupings on a resource server would need a client to understand the structu= re of the resource server, and thus fetch some sort of resource server meta= data.

I'm not underst= anding why you think this. Would you elaborate?
=C2=A0

Fourth and finally: Is the intenti= on to eventually recommend token binding here? Token binding as a requireme= nt across clients, resources, and the authorization servers would isolate t= okens to only being consumed within an origin. This would actually make red= undant/supplemental the AS additions defined within this spec (resource/ori= gin request parameter, =E2=80=98aud=E2=80=99 introspection response member)=

Token binding solves par= t of the resource constrained access token requirement, but does not solve = how the client authenticates to the AS.=C2=A0

=C2= =A0

-DW

On Jun 12, 2018, at 1:28 PM, Dick Har= dt <dick.hardt= @gmail.com> wrote:

H= ey OAuth WG

I have worked with Nat and Brian to merge ou= r concepts and those are captured in the updated draft.


We are hopeful the= WG will adopt this draft as a WG document.

Any co= mments and feedback are welcome!

/Dick
=
_______________________________________________
OAuth mailing list<= br>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth


--000000000000fb41d205715a599a-- From nobody Thu Jul 19 06:47:22 2018 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 84B1E130EA1 for ; Thu, 19 Jul 2018 06:47: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, 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 NWnLiV-JfdN7 for ; Thu, 19 Jul 2018 06:47:18 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::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 C99FB130E50 for ; Thu, 19 Jul 2018 06:47:18 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id o7-v6so3685741plk.10 for ; Thu, 19 Jul 2018 06:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J+F6/C8TlQBz/j89Xaclq39XRF9DnSi5HxVJRXkpNgg=; b=JtQ4R3IxF0VDPpcoudNOLKA9XU2BaU/9WmmLoU1Ytd8Uj7qQaC8ttPslSRvUDOueF8 LleC3L9M9KkQBIO8zO9z8dLB3KI30foaLmJ3kcnuUMNEn6HcLifhOo+OFcp0ILE+vAin WZyH8jZI2D3NSg6tO22t3EogICNakBeNz+Tdmf3mk6vlkWXU0T8UsN/YqKb0ydAdzMgC TGE3vjBxPuMLw+pP2w4gg1vPwhBQszBVDmvpqpvFw9UX49Us6d3GDj9qw+8SYm7cfvAV vV2FU6N0M5gyf47UP0JBT3NgnoQ7bf/SD2enYpRfvHKnmwS6/PtvHTsnlKutBLM5MNMv 7e7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J+F6/C8TlQBz/j89Xaclq39XRF9DnSi5HxVJRXkpNgg=; b=ThJtjkOJTUChCcG2Sva45BEhYDBx/4xANC5zCKl2NWwt6U6UtxHXY4pIEHXk5CVfR+ W204R7AJdEs0407JqlXo+D0F+hSgnokWObtRGoU5uHavIOe/HC+AxLhk3RBdaro/7v/D bm8sqOURYabOiMBAGzCQpa4i46UDecft4TmWy4HlaKymBzLgWVGRFQdCa5+xs8Wgu6fo iI5vzVG3/9x/K7jir9GvkgmmKpJjUpZS5ede0jkIc6wNRQ9DeyTM1ZaBx7mX5MoZyf39 s9RX2mcmj/jOUcd5dmBE8WTYY0vjFOyfX7TxS4fvJdA9S+dAMXBFnGrV8BJDp3lS5lXx ffSw== X-Gm-Message-State: AOUpUlEs6nkhK4oKESU5A2j/XDflbLAYAyyMERIlPGZmgKOR8LB7RH5R H1jaXL6Bdx9tg+e4JxbnvV03llem1/HCRmTOCWHrzym8 X-Google-Smtp-Source: AAOMgpesT33W05bGgD2NUo1KShkVMZJSQ3pW6CfvnrYalcfX7MUdftRwtQ2YBhTkTWOl6kBOzVIvWoTT5onXiz8c4kI= X-Received: by 2002:a17:902:b20d:: with SMTP id t13-v6mr10305259plr.121.1532008038158; Thu, 19 Jul 2018 06:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Thu, 19 Jul 2018 06:46:57 -0700 (PDT) In-Reply-To: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> From: Dick Hardt Date: Thu, 19 Jul 2018 09:46:57 -0400 Message-ID: To: Torsten Lodderstedt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e8555305715a6a12" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 13:47:21 -0000 --000000000000e8555305715a6a12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 19, 2018 at 8:51 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Dick, > > > >> >> Section 3: >> Don=E2=80=99t you think it could be a useful information to have the res= ource URI >> available in the authorization flow?I would assume it could have some >> additional meaning to the AS and could also be the context of the scope. >> > > I'm assuming you are referring to the Authorization Code Grant. Good call > out that the resource URI would be useful in the redirect. > > The use cases that I have been working with have all been Client > Credential Grants > > I currently don't know of a real world use case for the Authorization Cod= e > Grant for Distributed OAuth. > > > I think any scenario with multiple resource servers relying on the same A= S > for authorization where the client acts on behalf of the resource owner > qualifies for grant type code and distributed OAuth. > > Let=E2=80=99s assume a user wants to authorize a client for access to her= cloud > storage, email account and contacts when setting app the respective app. > Would you walk me through the user experience that happened for the client to do discovery on these three resources? In other words, what did the user do to get the client to call the resource and get back the 401 response? /Dick --000000000000e8555305715a6a12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 19, 2018 at 8:51 AM, Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:
Hi Dick,

=
=
=C2=A0

Section 3:
Don=E2=80=99t you think it could be a useful information to have the resour= ce URI available in the authorization flow?I would assume it could have som= e additional meaning to the AS and could also be the context of the scope.<= br>

I'm assuming you are referring to t= he Authorization Code Grant. Good call out that the resource URI would be u= seful in the redirect.=C2=A0

The use cases that I = have been working with have all been Client Credential Grants
I currently don't know of a real world use case for the Aut= horization Code Grant for Distributed OAuth.
<= /blockquote>

I think any scenario with multiple resour= ce servers relying on the same AS for authorization where the client acts o= n behalf of the resource owner qualifies for grant type code and distribute= d OAuth.=C2=A0

Let=E2=80=99s assume a user wants to auth= orize a client for access to her cloud storage, email account and contacts = when setting app the respective app.

Would you walk me through the user experience that happened for the c= lient to do discovery on these three resources? In other words, what did th= e user do to get the client to call the resource and get back the 401 respo= nse?

/Dick

--000000000000e8555305715a6a12-- From nobody Thu Jul 19 07:33:41 2018 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 D05BE1310CA for ; Thu, 19 Jul 2018 07:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 9QPi_4jKUok9 for ; Thu, 19 Jul 2018 07:33:26 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on072a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe55::72a]) (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 78658131093 for ; Thu, 19 Jul 2018 07:33:26 -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=KW9LgVE8mbtSJlFE5mMCUTD2Hfw0JW6uIAu6yv5o8FY=; b=k+76Mqnu9Em3TXj3FvUmHGxowNHUJMdtcKOIQDGSYenEgiTPqxEDvgaUPCaGlHrGoF309u8IyAw2+EesJSmSJowWae6ONBW6e4ej3yv1CZRKmFwDIOhxFb80vEy6Y/HOOHLEL1qO0640BOjJYB5BzkxTw3uv8QIUzHz9N5nfwe0= Received: from SN6PR00MB0304.namprd00.prod.outlook.com (52.132.117.158) by SN6PR00MB0350.namprd00.prod.outlook.com (52.132.118.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1015.0; Thu, 19 Jul 2018 14:33:24 +0000 Received: from SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::926:a011:7db6:4284]) by SN6PR00MB0304.namprd00.prod.outlook.com ([fe80::926:a011:7db6:4284%4]) with mapi id 15.20.1016.000; Thu, 19 Jul 2018 14:33:24 +0000 From: Mike Jones To: Rifaat Shekh-Yusef , Hannes Tschofenig CC: "oauth@ietf.org" Thread-Topic: Request for adoption of draft-campbell-oauth-resource-indicators as a working group document Thread-Index: AdQfbSo8vQ0hQlMlSHGSeBXaa0Ifbg== Date: Thu, 19 Jul 2018 14:33:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1232:144:b1ec:6be8:a2db:2240] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0350; 6:ebFXQRvK7KHyLeA8KYL2nr2+DB0Zm+o/jQdnSPZ+SrekMf0pqNkkVFgoEmuIki8OpxGQe615w/hmelFCMvfDaADzFXF3cRalh0nWo7JiNQg8NwqfeZn7CjQtluZVpF3OeTQ9n9Y3A/olY7+BFmWv2zHXVAhG8MROhvK2xP8ChAnBcmJYznezn/CQiGsHT9qC/7rWQOIloqYxO623R02peq2yiom+7+wqgKCLlr2e705sJ0xXzQCiurk3PV3WgERXgIzVLVQZCgFgNCj4ucxHfiJHoidQdJApIZh+5UHi++o5U1c84m08gtHxesc+nKE8cx1R7MtJODm5kjYmIZpTVrs+ihntrF/Vzl/MwwQddKp//6/2zjsY0WU26+RJkFeDMEIn52CUqpgIYWeO46CnKZa/3eO/4pG78aJI7W/e3wijocaqcFrZdYivd3fok5gKuN0yXfj+AIvEoCPeDw8f+g==; 5:5lfKsW5hpXNNf2cg8oFGaht4ql35j8ouHIS4fhQfyFYkJsakomPWrtbl8cwK6EnYGEBYR2JHSmZS5B4KtEppCXFQ1JN7VgdBN9gIBZhC72GCs/uVo1jMjWJijK6Yy7DlQEogdg10mlYNp+HWSsknfGsFbteYJwAscAnxemPWVl8=; 7:NI2yLDZ3gh8tQDRdKsoz4K/03eCjTVLacyJc7EZ5b4y+85CaphbH1c74iMtfRQOF++ypMAPAp9N5fDnZx1267bHKNdRGIgKcvimEcD/z5iLB2aNbzkk8PKYf7ZMbMmQORUYJsKMOsRPJdIim3rEBnO4yWI9/eUb3hPX5gRJAPu08FxJvm1Pf0hr3/yuqK/uxhmkqzrUi52nlFZRSlhxL/NMmRn1ykFnh/DoSkXLUMTKz23xmtipT8BZVUKRtP0Dx x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 48b112af-36c3-44c0-cac6-08d5ed849576 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:SN6PR00MB0350; x-ms-traffictypediagnostic: SN6PR00MB0350: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(2018427008)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:SN6PR00MB0350; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0350; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(396003)(136003)(366004)(189003)(199004)(7736002)(10290500003)(2906002)(316002)(22452003)(478600001)(5660300001)(25786009)(72206003)(14454004)(6436002)(966005)(256004)(14444005)(6506007)(4326008)(7696005)(110136005)(39060400002)(102836004)(53936002)(606006)(86362001)(790700001)(86612001)(6116002)(54896002)(33656002)(99286004)(8990500004)(186003)(486006)(106356001)(8676002)(476003)(105586002)(46003)(2900100001)(5250100002)(97736004)(55016002)(6306002)(236005)(9686003)(74316002)(8936002)(68736007)(81156014)(10090500001)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0350; H:SN6PR00MB0304.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) x-microsoft-antispam-message-info: l0MOGJsYuoNoXuH/jagyDpynNSWVXflrgnxtHbF7QOhpFEuCNwtKHJALJY8KMSYQ3ydN0FUCL2xolxrBy+7hE0EkgGKxdE4YizcmJg03DjMCbicAw8ZPhhPCkVjOi0qemLkFuBaeLlrK/a7Y2lvhGceF/qRymR99iHV/VvSarRyMZR35FxfBjAVnHJU877PjnaMzinUdvO0VJbc2mOQVWwOeHWmyFdzmWcgyrR4XWvsEIUwgjrYcNv6CWo/VHfSC5MdkOtYYghiKpIVXsgCdkpViky7Ufzw9LQXaff76AF7R9hVZurzdAxOGOhuMkwBkpOrb5CMcyahPF8PLRlX0HKAto6XTy+dkOe0MSuCNGHI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR00MB0304898B535F0BCD9811EBE1F5520SN6PR00MB0304namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 48b112af-36c3-44c0-cac6-08d5ed849576 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 14:33:24.0268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0350 Archived-At: Subject: [OAUTH-WG] Request for adoption of draft-campbell-oauth-resource-indicators as a working group document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:33:34 -0000 --_000_SN6PR00MB0304898B535F0BCD9811EBE1F5520SN6PR00MB0304namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 def= ines the already-commonly-used "resource" request parameter. At today's wo= rking group meeting, several people spoke up saying that they need a parame= ter with those semantics. I therefore request that the chairs do a consensus call on the adoption of = draft-campbell-oauth-resource-indicators as a working group document. Thank you, -- Mike --_000_SN6PR00MB0304898B535F0BCD9811EBE1F5520SN6PR00MB0304namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

https://tools.ietf.org/html/draft-campbell-= oauth-resource-indicators-02 defines the already-commonly-used “r= esource” request parameter.  At today’s working group meeting, several people spoke up saying that they need a parameter w= ith those semantics.

 

I therefore request that the chairs do a consensus c= all on the adoption of draft-campbell-oauth-resource-indicators as a workin= g group document.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Thank you,

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

 

--_000_SN6PR00MB0304898B535F0BCD9811EBE1F5520SN6PR00MB0304namp_-- From nobody Thu Jul 19 07:34:44 2018 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 7018E1310C1; Thu, 19 Jul 2018 07:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 cjFcfHsqIlzt; Thu, 19 Jul 2018 07:34:30 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00082.outbound.protection.outlook.com [40.107.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F3A1310C2; Thu, 19 Jul 2018 07:34:29 -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=CGgvxuLhCtMahOPAqoPASkf7fGLud62OPATYuaIEgiA=; b=olVU0OcBPI7Go5KcRy0UGB2Juy4tZyh9O3EXUYuWYhWTFpAnAUpGNcKUo4gQfCosAATvUScge9Vr9hvaw0bselSf+3yNYos9wdUBES4ZZkFp6TqDMkeghFZk7PvbrEEX1/nbmu0FpHVyRhyU8CALaRWWrEWZJbaKeWZdWc/LaA8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1616.eurprd08.prod.outlook.com (10.167.211.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.20; Thu, 19 Jul 2018 14:34:26 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Thu, 19 Jul 2018 14:34:26 +0000 From: Hannes Tschofenig To: Benjamin Kaduk , Eric Rescorla CC: "ace@ietf.org" , "oauth@ietf.org" Thread-Topic: ACE - OAuth Synchronization Thread-Index: AdQfbMNLxMX6hvBdRCO/rve3G6chAg== Date: Thu, 19 Jul 2018 14:34:26 +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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1616; 6:Naa8ODf9TnV0XeAvDsjCEKmU7RAoeTEGuf+OIYhDUbSimo6WZSW/o6ako8sgJSVfQG9TK8BZGk8n7ifSFo7BosCrf9JlUELkTALgDWb7Vf2WOaYhu4dO+QIn/BCGjFAdkXYTi8oGapni//V7GnTAr7lzGOdnxZVPSyt8Ji4XK93FxrIXi3DLuj40OG7XG2c9Gv8e0x7JQDtoTZe1kMQ5L1f7oj94dnUVsNtqOaxV0wH/9MfHxd3Nr7q4NNOgeEYN8IhvIiv6V6RJiRxN/jNvULPlKusoqIbzngHWf3ypx0Kqb2UgKNyVVeiEdAeDwEQcyjvsFBFzF5sLu5dceVIj8Izo0L98mcePlnR04Mr2PTyW7qi/URXfeKGBh23aeiHo3CGSOmqNmseNQN5WpxY48ezDDW8uJfhXzZejOTnhgsPGRW9nUIuMN0ma4QipfnUqGPP3b0RIfqBFBWOA4WTMkg==; 5:vDfdHdZaL2yWjlPuLiMIvKtxkQW/xn7FRxc+3igjRPNewzUdQGAw2uI16B/AtcWQfx/FIGj16Sr4NZdQm1wIuGNmH4VmPdlGtqmAr+ex+TUDcUltnAoOQhbXoPjmsyfaOvX4D3YNKr2fzBQttQYphyebA9pJ48Qm7xYT8DCkins=; 7:xqv7JihLru9qm5RGJ99N1XGgh8iRORPEHr4JnH3mxkRGjME8eYMYc6OCkJbTMACDXZ0xvM8ecMIw5wOUZ6egPnIFhFf/5jOSJKHJOeVO8Gxzi+g0i5q+g9QhWajGS17qrcYCs8LYrOt0n4R7gPUyUGIqo5xhoWfrizOOHFBW9Lm1c4td476RTKzWT203ET1USBZnOUw4fbeucFcBffPyRAhIWS9xwiKD540pD08MOrpzzec+FgMbYhdCajAl6aKd x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 796685cc-2e51-4adc-9013-08d5ed84baa2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(48565401081)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1616; x-ms-traffictypediagnostic: VI1PR0801MB1616: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1616; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1616; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(136003)(396003)(39860400002)(40434004)(189003)(199004)(81166006)(81156014)(25786009)(14454004)(33656002)(72206003)(478600001)(486006)(2171002)(476003)(4326008)(53936002)(8676002)(2900100001)(97736004)(106356001)(105586002)(2906002)(66066001)(99286004)(5250100002)(8936002)(68736007)(9686003)(6436002)(110136005)(316002)(54906003)(55016002)(54896002)(74316002)(3846002)(186003)(790700001)(5024004)(102836004)(6306002)(256004)(26005)(5660300001)(14444005)(6116002)(7736002)(6506007)(86362001)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1616; 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-microsoft-antispam-message-info: s/bkTQF3EyG16IdDnQIhkXsGyct0LIwQbtovz0OmUAfU5PM5jp92hmL+CKNuLodHqX7cgC7OXcxscV8Z1IRqGbZQBeid53J3IPfztWN8nvUBiq5dM8W12Todlyn+bJR2SoEVMvBxavsDdc9yxB95l3FULle9HWoteBMZgzeAHvkNs7NjrRVs3uuO2Vttkzox/ivHWsFjLZRLgpRnkloYk4S7iIUeQb7lsf83x9crbF4ELAqy1nbFWcibrXVKxszTBsfWep+NllTb3KCill1kn9/vfxFeSYLcr/L1d8zesFM3as/wE4h8z81csd8hlihIDfJJr2Vs+W+Ox2Ljh+8hV9jpDdsM8yLOtjvvCZWUh0I= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21122B372DBC82EFF5BD98AFFA520VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 796685cc-2e51-4adc-9013-08d5ed84baa2 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 14:34:26.3713 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1616 Archived-At: Subject: [OAUTH-WG] ACE - OAuth Synchronization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:34:43 -0000 --_000_VI1PR0801MB21122B372DBC82EFF5BD98AFFA520VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben, Hi Ekr, We tried to find an agreement of which group defines parameters needed for = ACE to support the PoP token functionality. Unfortunately, we didn't manage to find an agreement in which group the wor= k should be done. The ACE working group wants to start a working group last call on draft-iet= f-ace-oauth-authz in September. Hence, there is some urgency in making a de= cision. We need your guidance to avoid having the topic bounce back and forth betwe= en the two groups. 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_VI1PR0801MB21122B372DBC82EFF5BD98AFFA520VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ben, Hi Ekr,

 

We tried to find an agreement of which group defines= parameters needed for ACE to support the PoP token functionality.

Unfortunately, we didn’t manage to find an agr= eement in which group the work should be done.

 

The ACE working group wants to start a working group= last call on draft-ietf-ace-oauth-authz in September. Hence, there is some= urgency in making a decision.

 

We need your guidance to avoid having the topic boun= ce back and forth between the two groups.

 

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_VI1PR0801MB21122B372DBC82EFF5BD98AFFA520VI1PR0801MB2112_-- From nobody Thu Jul 19 08:12:13 2018 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 9999E130EAF for ; Thu, 19 Jul 2018 08:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 SpqjfTomKLhY for ; Thu, 19 Jul 2018 08:12:05 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0061.outbound.protection.outlook.com [104.47.1.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C85130E84 for ; Thu, 19 Jul 2018 08:12: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=SHKF9cXAG5Xomz9EDb5jwD32Rj0AgkhygLwyflUFbTk=; b=rD9Df3pYub4Gn3x/IYLWg3ja+2S9ODP7Zelx7Bkx8XGq2GdbFaql6ZM/CQMLT59K1oC/TKcmMtxWhBmHLUkryiuWChP0l4RSDnKzpYyUwR25na0aRCpyK/N1mzM0xGzbA4LCP7Hf4Ox6vv4weROBWOVTpVUxEaTBjbOZ3E6bUO4= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1838.eurprd08.prod.outlook.com (10.168.68.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.19; Thu, 19 Jul 2018 15:12:02 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Thu, 19 Jul 2018 15:12:02 +0000 From: Hannes Tschofenig To: Mike Jones , Rifaat Shekh-Yusef CC: "oauth@ietf.org" Thread-Topic: Request for adoption of draft-campbell-oauth-resource-indicators as a working group document Thread-Index: AdQfbSo8vQ0hQlMlSHGSeBXaa0IfbgABXtgA Date: Thu, 19 Jul 2018 15:12:01 +0000 Message-ID: References: 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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1838; 7:QuomLhSQMg4Gi5E4rExQESh+Hk2vJqgBVeSbmaxmVoOz3m1+SZ510zTND4QKXlVeV/esY3WsYGT76LgT1vhGmeqJVmnYJWSbzrwOIlGeDVWmQZwyDzrzQQ+Dp10Pa5duaED1xqBpuX7EovYxxw8oW4h/ztiY5oJF4wkpxC6W3j/qAm29bmldUZkOcbkPdyZy5xgCqlhe4BMNq/licADtpXelCiE+XS4G7FzubjbEuKv8xuR/Zh3GVRa6O7B+yNj+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ce214574-206b-465d-18b0-08d5ed89fb0f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1838; x-ms-traffictypediagnostic: VI1PR0801MB1838: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1838; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1838; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(346002)(39860400002)(366004)(136003)(376002)(40434004)(199004)(189003)(68736007)(11346002)(53546011)(236005)(102836004)(5660300001)(606006)(9686003)(7696005)(54896002)(8936002)(6306002)(6506007)(25786009)(4326008)(6246003)(76176011)(55016002)(39060400002)(229853002)(53936002)(8676002)(7736002)(186003)(486006)(66066001)(476003)(86362001)(26005)(1511001)(81156014)(74316002)(81166006)(6436002)(478600001)(2900100001)(72206003)(106356001)(790700001)(6116002)(97736004)(3846002)(14454004)(105586002)(966005)(2906002)(316002)(110136005)(446003)(5250100002)(14444005)(99286004)(256004)(33656002)(5024004)(45080400002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1838; 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-microsoft-antispam-message-info: +VOZhduE2Oya32CxpyhzN7cHGH7lu8OpaaqQwAgGqK8GvQIGEPlAXEXhl6emtxfA98PQ8MDIWuJKRVhj1m7VVPSfOpn6ZlUWHqLsK6XgDEpFzZv2iOZF2dto00CkWDW+QPmb65yVYJB4G+zbROMi1yWeAVx/RHa4DR+Dcp94+3EelV7eN6rEp3nCmzaJTCxl3IXcI+zSearq1vwuuza70wx8zqKuYX3fytnlgmsNjHUeDVRGl4/JNCpA8zhqkVp+ize0whNmT1eDNs9tqNvNlz3eKRk74THXFyVWBR1JV991fv+K4FecpPjrACUB0R76FXMXS3kB031UrTZ0SV9gfbq+CSNM8K66qh74pxFhE/8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21121361CA7C51F7534B1865FA520VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce214574-206b-465d-18b0-08d5ed89fb0f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 15:12:01.9504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1838 Archived-At: Subject: Re: [OAUTH-WG] Request for adoption of draft-campbell-oauth-resource-indicators as a working group document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 15:12:10 -0000 --_000_VI1PR0801MB21121361CA7C51F7534B1865FA520VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To those who haven't been at the f2f meeting: We did a consensus call durin= g the meeting and the result was a strong positive confirmation from the pa= rticipants with no objections. Rifaat will have to run through a call on the mailing list to get the confi= rmation. Ciao Hannes From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: 19 July 2018 10:33 To: Rifaat Shekh-Yusef; Hannes Tschofenig Cc: oauth@ietf.org Subject: Request for adoption of draft-campbell-oauth-resource-indicators a= s a working group document https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 def= ines the already-commonly-used "resource" request parameter. At today's wo= rking group meeting, several people spoke up saying that they need a parame= ter with those semantics. I therefore request that the chairs do a consensus call on the adoption of = draft-campbell-oauth-resource-indicators as a working group document. Thank you, -- Mike 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_VI1PR0801MB21121361CA7C51F7534B1865FA520VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To those who havenR= 17;t been at the f2f meeting: We did a consensus call during the meeting an= d the result was a strong positive confirmation from the participants with = no objections.

Rifaat will have to ru= n through a call on the mailing list to get the confirmation.

 

Ciao=

Hannes

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: 19 July 2018 10:33
To: Rifaat Shekh-Yusef; Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Request for adoption of draft-campbell-oauth-resource-indic= ators as a working group document

 

https://tools.ietf.org= /html/draft-campbell-oauth-resource-indicators-02 defines the already-c= ommonly-used “resource” request parameter.  At today’s working group meeting, several people spoke up saying tha= t they need a parameter with those semantics.

 

I therefore request that the ch= airs do a consensus call on the adoption of draft-campbell-oauth-resource-i= ndicators as a working group document.

 

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            Thank = you,

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            -- Mik= e

 

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_VI1PR0801MB21121361CA7C51F7534B1865FA520VI1PR0801MB2112_-- From nobody Thu Jul 19 08:51:32 2018 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 102F1130EAB; Thu, 19 Jul 2018 08:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 flBFaXWZnaLd; Thu, 19 Jul 2018 08:51:21 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 8DFD21310DB; Thu, 19 Jul 2018 08:51:21 -0700 (PDT) X-AuditID: 1209190e-33bff700000068b9-f8-5b50b378cd95 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D6.82.26809.873B05B5; Thu, 19 Jul 2018 11:51:20 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w6JFpJQD005291; Thu, 19 Jul 2018 11:51:19 -0400 Received: from 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.13.8/8.12.4) with ESMTP id w6JFpEEn020497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2018 11:51:17 -0400 Date: Thu, 19 Jul 2018 10:51:14 -0500 From: Benjamin Kaduk To: Hannes Tschofenig Cc: Eric Rescorla , "ace@ietf.org" , "oauth@ietf.org" Message-ID: <20180719155114.GN79497@mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IRYrdT163YHBBt8GKelMX3bz3MFiten2O3 uDnjFJPFybev2BxYPNbMW8PosWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgyphy9ylrwk6Pi 9UbOBsYp7F2MnBwSAiYSy18tZO5i5OIQEljMJHFh/hpGCGcjo0TTnIlQmbNMEv8urWAEaWER UJW4+mU9WDubgIpEQ/dlZhBbRMBQYm/zIVYQm1kgW2Lzw59MXYwcHMICGhJvH1aBhHkFdCSm PngBViIkkCBx7W0zO0RcUOLkzCcsEK1aEjf+vQRrZRaQllj+jwMkzCmQKLF4xlOwTaICyhJ7 +w6xT2AUmIWkexaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpGuvlZpbopaaUbmIE BTCnJN8OxkkN3ocYBTgYlXh4VzgFRAuxJpYVV+YeYpTkYFIS5a067xctxJeUn1KZkVicEV9U mpNafIhRgoNZSYS3YANQOW9KYmVValE+TEqag0VJnDd7EWO0kEB6YklqdmpqQWoRTFaGg0NJ gvf/RqBGwaLU9NSKtMycEoQ0EwcnyHAeoOEnQWp4iwsSc4sz0yHypxiNOeYdnTqJmePPeyAp xJKXn5cqJc7LsgmoVACkNKM0D24aKAlJZO+vecUoDvScMK86SBUPMIHBzXsFtIoJaJV0tS/I qpJEhJRUAyPjA9fLRSwtaRtezNf4bVgrvvTjltwmzd+Tv32UYjjsFGVs5TT7SfKR7YnGjFfO Bl2Z2CUyb8P+BWyzvVZc1F91eDO/uWdaZXnXu9N3KiQqPrwuK56z9/eVK3Zvjlx8ymX5z1+Y LY17Wre7nYDQq2qlhaumnNm6/VPOS82E9/19qy/vUjJ20o9QYinOSDTUYi4qTgQARd4DmR0D AAA= Archived-At: Subject: Re: [OAUTH-WG] ACE - OAuth Synchronization X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 15:51:25 -0000 Hi Hannes, Can you remind me which parameters are being problematic in this regard? I mostly only remember the ace discussions of keyid, recently, so I probably lost track of some relevant bits. Thanks, Ben On Thu, Jul 19, 2018 at 02:34:26PM +0000, Hannes Tschofenig wrote: > Hi Ben, Hi Ekr, > > We tried to find an agreement of which group defines parameters needed for ACE to support the PoP token functionality. > Unfortunately, we didn't manage to find an agreement in which group the work should be done. > > The ACE working group wants to start a working group last call on draft-ietf-ace-oauth-authz in September. Hence, there is some urgency in making a decision. > > We need your guidance to avoid having the topic bounce back and forth between the two groups. > > Ciao > Hannes > 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 the information in any medium. Thank you. From nobody Thu Jul 19 10:43:54 2018 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 22362130DC6 for ; Thu, 19 Jul 2018 10:43: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 qcJiUNTVOQnM for ; Thu, 19 Jul 2018 10:43:50 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 1CB50130E05 for ; Thu, 19 Jul 2018 10:43:49 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id l14-v6so7766956iob.7 for ; Thu, 19 Jul 2018 10:43:49 -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=iaQxBeSBr+NzrqNKS/P7enAXr3j3jimRR7JF1seaBHY=; b=X6Y2EYSXN938TNa/rSXaoFu0Sz4I8fl0F521CphFGk3hkW/pubG/KWijNKxSP+qrCv CKfDs4FIIxisSyfKyucgf7GaMcDMTDSLqomQHRKPPhDSXj7C6hH9IVaw+ttinProLLdZ 3XhDQtZGWRRpOtbCTo1qlDTsyDE043SxSXH8i9x6DxuI3jGbQRw/O7ukzCOOv0WOL+GN DmMSGaYm/0nXFcBh60Na+kTzP3g8nha474dMWZg/Hm1hLW0lD1ij9yer1y+wu2ZUlgNA BpEdYx9SQPcimpfcKkvpvX/5HhkcQKGtozTtId1nAGuzJd4OYaZ1oD03lIL1u/Cj7BwZ oZWg== 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=iaQxBeSBr+NzrqNKS/P7enAXr3j3jimRR7JF1seaBHY=; b=KGZ/dp++kyuAvl+ANBoH9xXi8J6gQDas9wsBbyt5+ME9YExCKqgCuu/4DVMb89fWZ7 ZzeqvCXdbiaiC8RIB6nLREpA2/SK6LU6gOKRZ+1T97RKAAWTZLbDvurT0hEyZ/GTjxcs opwUP0dnO98pEQqoMcLvIdmHox81HKuZOoKqZNMSoQEji3X4+OVkp2sQqNEc+Ifa4Gx7 +z8I42kdtzrvrSqGcbgzrv7cFfQnFjWLqUvBcSqPxiNHdbG+QJjCwVbN5yyq6SlHHkLE Ung19P3/vhkU7jFkTU3Wq4ieep4MctIAAY3bSJSF8tIJ+mOejOhLm3gTCFS8a0pJ/LGG 661A== X-Gm-Message-State: AOUpUlHzlkdFKz/BYPDcMCrdLWOo2Z+qwuVUlwwMzkeSYrykf0ymLMJp /ViAhC44hnDG3wY/vimEiO7AW0ftqbzSbBi7CG5ALZ+BlMo= X-Google-Smtp-Source: AA+uWPw/wcyEcxw77cE67CPzr9Sffrmooj1DAtjo3FIZtHwUEmCZcE4sgXPHFCzfAiWcjquoi76oR3e4Xt1pJRG8KXo= X-Received: by 2002:a6b:410a:: with SMTP id n10-v6mr9864986ioa.0.1532022228266; Thu, 19 Jul 2018 10:43:48 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Thu, 19 Jul 2018 13:43:37 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000b4334d05715db833" Archived-At: Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 17:43:52 -0000 --000000000000b4334d05715db833 Content-Type: text/plain; charset="UTF-8" Hi all, This is the call for adoption of the 'JWT Response for OAuth Token Introspection' document following the presentation by Torsten at the Montreal IETF meeting where we didn't have a chance to do a call for adoption in the meeting itself. Here is presentation by Torsten: https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00 Here is the document: https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01 Please let us know by August 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Regards, Hannes & Rifaat --000000000000b4334d05715db833 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

This is the call for= adoption of the 'JWT Response for OAuth Token Introspection' docum= ent following the presentation by Torsten at the Montreal IETF meeting wher= e we didn't have a chance to do a call for adoption in the meeting itse= lf.

Here is presentation by Torsten:

Here is the document:<= /div>

Please let= us know by August 2nd whether you accept / object to the adoption of this = document as a starting point for work in the OAuth working group.

Regards,
Hannes & Rifaat
--000000000000b4334d05715db833-- From nobody Thu Jul 19 10:51:29 2018 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 23861130DE4 for ; Thu, 19 Jul 2018 10:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 MM677-BKmbYJ for ; Thu, 19 Jul 2018 10:51:25 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 5939D130DC6 for ; Thu, 19 Jul 2018 10:51:25 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id g18-v6so5754475uam.6 for ; Thu, 19 Jul 2018 10:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NluyYWY9Zp6qlMV+ZtIKX+oGLoJ3lZfwMOpcT9QIWfo=; b=VgKMlUpKdcQI3hlgu5MjCMFRuH6UTbnhLJ6f7kJzAToaST2WqNSaZEa/5B3zyzORQk kqk0Q+grI7VModJmGS8HXYhfFG8utizwU2u9quloXKoSmAK+GVJCyVHT7TQpBlYJHBby 4pkvcD1/KmmKwSs+ZwzIZfL7OmCQezrlE3Q2GVQTEoFAOCn5ciMa0tVQ6LBvydnTo+TS hdgg9uiJs+K6UyxAjRMzLhKA4EybeZ8iDeIyniGfWC8Q/SbIkQThcSDAGlmPoNEd2um8 l0izNyZCxf+Za9/JoyaaTIgvcxXB+DxU4sa9T9+egbeey1aTFmAgBeDxjWrM8Fm+xv2j +SGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NluyYWY9Zp6qlMV+ZtIKX+oGLoJ3lZfwMOpcT9QIWfo=; b=Vbsy975cDdyV1X54AhTt1EIlXYlLrSmn8KMrlW7BetJa6vr0N33i+4NnGanwQzm1fi HE6U0yexRlzdY+CMLs05lXBaFyO9EzJ2J9i8yLYj/vvJbGbdrodIus+rgAGrIctO1M32 jwSitslc96s4ALBellzl3d71QQdQZJY+dKNxx0uYN4kFFBnEX8GwC+psNvpr8uooGpZN 8mTeAjRpDZCHD9MduAc8dfjAoGtjDTtki3HasQ7gW9ocHtcEK+5obZ0w6BmFfAoF7Wjv YUWDNGtp7x1rxRzCcoR/SbJlDltu5+yCqPT4f010lC+MWM3OwL8OADexCmkzkADptZU9 ulQg== X-Gm-Message-State: AOUpUlH/V3aopcS5P/tdnvFShY+onRUMQQRciJBH0FmYD0whzCRsIfWc 1q1ov7SM4PkFC96+TGc6leu3b+ITKNColQYpKtU+cA== X-Google-Smtp-Source: AAOMgpdcFMQn8eqrfVG8YiI/Z2epUr6ltL29y9PPEuI4mTSgnM+3uuN/IydyrNaUjb4NOKXSCxJHRiCaAYEQB31n8oQ= X-Received: by 2002:ab0:234c:: with SMTP id h12-v6mr791473uao.161.1532022684020; Thu, 19 Jul 2018 10:51:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:6383:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 10:51:03 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Thu, 19 Jul 2018 10:51:03 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="000000000000dee49805715dd31b" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 17:51:28 -0000 --000000000000dee49805715dd31b Content-Type: text/plain; charset="UTF-8" I support adoption of this document by the working group. On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef wrote: > Hi all, > > This is the call for adoption of the 'JWT Response for OAuth Token > Introspection' document following the presentation by Torsten at the > Montreal IETF meeting where we didn't have a chance to do a call for > adoption in the meeting itself. > > Here is presentation by Torsten: > https://datatracker.ietf.org/meeting/102/materials/slides- > 102-oauth-sessa-jwt-response-for-oauth-token-introspection-00 > > Here is the document: > https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt- > introspection-response-01 > > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth working > group. > > Regards, > Hannes & Rifaat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000dee49805715dd31b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of this document by the working group.<= br>


On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef <rifaat.ie= tf@gmail.com> wrote:
Hi all,

This is the call for adopt= ion of the 'JWT Response for OAuth Token Introspection' document fo= llowing the presentation by Torsten at the Montreal IETF meeting where we d= idn't have a chance to do a call for adoption in the meeting itself.

Here is presentation by Torsten:
Here is the document:

Please let us know by A= ugust 2nd whether you accept / object to the adoption of this document as a= starting point for work in the OAuth working group.

Regards,
Hannes & Rifaat

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


--000000000000dee49805715dd31b-- From nobody Thu Jul 19 13:02:09 2018 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 0AA68130E8B for ; Thu, 19 Jul 2018 13:02: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 j99Ji_5nZfEo for ; Thu, 19 Jul 2018 13:02:05 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 633B6130DC9 for ; Thu, 19 Jul 2018 13:02:05 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id d70-v6so3246526ith.1 for ; Thu, 19 Jul 2018 13:02: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=5fP+UF+5g7vcSNDWWOU3GBNWZNp7NuJO677x3eSiU6A=; b=MgtSl+6setyzyRHeNdyurKgYFmcse7nW1JCg42VidOPahBmyPuJ9AmdhYzvqIv2ko1 yArvlDusFt1BDEbbPuyL29bQbpLcfVBU/i3sSWPyA4F7fjSmcu9fnCeIrzB180cbbrKi 60YzxAFCbUNwQH0wVLQ3/+eZ9amZaS3BeNJNrnqNlH8RpATU9qkv6svNalJUves1VhKt 6kMOUccVPMFKfmVkChf8lC79XEXptWpUR7aUJsSPpgmtXz7gyqXFnbFuOaOxJ27VcV2P +oFEcQGEyYpmm0ys27/qE9zRIhyJuxXx+aKQfoRnWMgy14ylbfnHnaiEsrgUTEtZc/Of 3M+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:from:date:message-id:subject:to; bh=5fP+UF+5g7vcSNDWWOU3GBNWZNp7NuJO677x3eSiU6A=; b=LTu7kLFWrhCuXssaaFCBqiFCuFzaT0VsqMvLSfe1X8G3Cfgd5GPX3mPXiOTFQe7gzg vk1fB42SKdf+0J8Gzf1mswWbVygd2Is91dTWZ7IF8ZPM6hjdj0glhCmw5Eqp3JR5ZBIL Q1yMAcuGCUUW2iBumtxzoDT39acAwhZEOkSyB/4nTrMob+jmDeSCGm/G6Bo83BhtPZUh QiFb/0LmZUwMvvU0iIM7zRTyXK0JNKGuQUTn7G9EB8VwLJfy+IlibURzoDsFtCSRP2p3 brKrS9+Q24QwgyHLMoO76z1/8VN2zbNTeDNcpQ2NuPWqucoUsACcNPBDKVPWQgAND1mW o+Ng== X-Gm-Message-State: AOUpUlExcfP66RyHm7iTUy7as69BeIDO2X8xkrPncv9nQvYcmSbtwdyi qFgGR0USl7lHAO0oQ+mx8C7/QvJx79tmJ4CKZB1NA0Ki7LI= X-Google-Smtp-Source: AAOMgpcOdlwfItFWrWT42yt3DEtqa7FCBYbyGXYv4YgDMxYIl227mG2VDiKQ1tM8ahJipLvh3gMV635/4V8aui0S5kE= X-Received: by 2002:a24:c445:: with SMTP id v66-v6mr6839338itf.110.1532030524544; Thu, 19 Jul 2018 13:02:04 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Thu, 19 Jul 2018 16:01:53 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000335d1e05715fa764" Archived-At: Subject: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:02:08 -0000 --000000000000335d1e05715fa764 Content-Type: text/plain; charset="UTF-8" Hi all, This is the call for adoption of the 'Resource Indicators for OAuth 2.0' document following the positive call for adoption at the Montreal IETF meeting. Here is the document: https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 Please let us know by August 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Regards, Rifaat --000000000000335d1e05715fa764 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
This is the call for= adoption of the 'Resource Indicators for OAuth 2.0' document
following the po= sitive call for adoption at the Montreal IETF meeting.

Here is the docu= ment:
https://tools.ietf.org/html/dr= aft-campbell-oauth-resource-indicators-02

= Please let us know by August 2nd= whether you accept / object to the
adoption of this document as a starting point for = work in the OAuth
working group.

Regards,
Rifaat
--000000000000335d1e05715fa764-- From nobody Thu Jul 19 13:06:06 2018 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 49B46130EB2 for ; Thu, 19 Jul 2018 13:06:05 -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 uzqvaUvryo0e for ; Thu, 19 Jul 2018 13:06:02 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 01037130DC9 for ; Thu, 19 Jul 2018 13:06:01 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id w16-v6so11617996ita.0 for ; Thu, 19 Jul 2018 13:06:01 -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=4ozkWx7W1Dm1dajWT3Nihd/DLcmUBeoKHFRn4A/sy/E=; b=iL0XyVRKMXsog8YAyqzX44U+EChhto6lVylgY5hTX169FQrHFP5Jzt5DnRpoN7+dUU b8klGBya+jLagyx1CLC+lfV46K4a3z6I+qUqpELIToBiq4VryZ/nSkQ3ZBs430HAM+Oi qbQmoAjLOYlOM2aFC7uLTabpQNn4KV6uWOfXhekgQICyr3XrXEx2L1o58v/pqOHqGVI7 UvCBJMNZQNO6nNSQZ0cfJmlSSNArnPjq0akdLNc3UzdcnoWdxjB4ytL89fl6KXhhVxvP 2ySn8g5siTlF7ksWWYqOjXCgkALCe/kIl8PaERNfipZip1ac39zN6Y6OTIO28Tno7kja F+fw== 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=4ozkWx7W1Dm1dajWT3Nihd/DLcmUBeoKHFRn4A/sy/E=; b=SJKTOaziVEVW4zjwiQxJRlC5U0edaoOlh+yPn9uwnJvF6X1fh6viCG1udwQQRqAP5n c7QtdC4BzTjd9QF8IPkEKaVYZPVkxlG6WBk+MFga3/JAnrpjnJAnOYLtSCElvM7TSyss MAdgdmeloJ47VuwXttjidwaFFn2T2szkglTBFXC6zsJ9JlHaoBVWDLC8Jm+9u+8bTAUO J49Nam83xEjOXSmol57d9oA8Qrf7/mSHxxmtNB9mXmkAoE4eJ2a6ZFLSAkZ0PxQgZp0l OlCF7slWvjVvJW9rbWa2YjW0W0Ig9Nl22LOzFJOQZo4M+hXAHcqVwfcMTjgeUvN2M8hl SRzg== X-Gm-Message-State: AOUpUlFq/JOA5UImOM/qpM/7KBtKnzVxEfKAVbZmcO3aROCapuVy+dzX gLpgc/pjTfFCpdPBCIZjG06r09da35R9/fr49tobjaQSZ1g= X-Google-Smtp-Source: AAOMgpdb/4gbfI5+N+D3UcZzHF1weiD6zRHXXzjA0OWaRtpJ/fRj9U0D+8m8vha+/xkygsrE6F3MjFBodiA8bXBMOg4= X-Received: by 2002:a24:c445:: with SMTP id v66-v6mr6855568itf.110.1532030760968; Thu, 19 Jul 2018 13:06:00 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Thu, 19 Jul 2018 16:05:49 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000004aeb4505715fb52c" Archived-At: Subject: [OAUTH-WG] Call for adoption for "Distributed OAuth" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:06:05 -0000 --0000000000004aeb4505715fb52c Content-Type: text/plain; charset="UTF-8" Hi all, This is the call for adoption of the 'Distributed OAuth' document following the positive call for adoption at the Montreal IETF meeting. Here is the document: https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ Please let us know by August 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Regards, Hannes & Rifaat --0000000000004aeb4505715fb52c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

This is the call for= adoption of the 'Distributed OAuth' document
following t= he positive call for adoption at the Montreal IETF meeting.

<= /div>
Here is the document:

Please let us = know by August 2nd whether you accept / object to the
adoption of= this document as a starting point for work in the OAuth
working = group.

Regards,
Hannes & Rifaat

--0000000000004aeb4505715fb52c-- From nobody Thu Jul 19 13:29:20 2018 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 32E19130E2A for ; Thu, 19 Jul 2018 13:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 CjU72hod01RL for ; Thu, 19 Jul 2018 13:29:16 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2D1130DC9 for ; Thu, 19 Jul 2018 13:29:16 -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=R4MEZU3s2+J23Lnhp6+47P+yOXgVyvF4dYeBcgJGQGM=; b=irjcKStuwcrPAA6cw5JvPn+aHdlW4ANyGNK69fdecBLWT5kbbOcehGU+aa5+GOG4IkkO99XdUAsD74f60N54aX4nH4LfP8Wy0XVFxqV3yNJn9h2u+cgOKCFbhd9bXSyW6UNimeguTv34ubb7b2xS0hlbJA15mSwyriZ6A9ICBFw= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (52.132.128.37) by DM5PR00MB0294.namprd00.prod.outlook.com (52.132.128.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1015.0; Thu, 19 Jul 2018 20:29:14 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::ccd4:2ea:171a:e326]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::ccd4:2ea:171a:e326%8]) with mapi id 15.20.1017.000; Thu, 19 Jul 2018 20:29:14 +0000 From: Mike Jones To: Rifaat Shekh-Yusef , oauth Thread-Topic: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" Thread-Index: AQHUH5tpAEJtgz4Ml0eD0vJ2JOwxQKSW/s9Q Date: Thu, 19 Jul 2018 20:29:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1232:144:a03e:93f:7764:5cc7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0294; 6:IhaCSKEyssctyx4626NkxtukAnNRxl2TQPdHjfcjnZtRxeN1Ba84jGRJ3GCck7BAn7xDGebIh4FIUxosxFgx+fbf/3dvWkOwyXqWjZv7pgDZtWLhF5OJrHzLHdvPfkM4WyXB667/c6HS0aCxI90qixWFPMxnHnR04RUFoinAlNkRbu3K0OYu+NGxQUCc6gfFJQEeG+fSv4Vt2C82EZKPuYm8sd4bfQ9cEGNxQK39AYb3v29NE2IhJ1ceW68i9pXYSLNls8yRUD6FTqB7LmbRWuhzCGa1wostV0TJm1y1ES8cadQHH850nm+RjUK7u6KyJFFvvQhLT6fSt9ZWHNlxEn0+XKdHoYdjV1NtyM7hV1OWGlJsDlfeA7WPUIJRqbyU8b3FIrUA89+Ko26ziAe4qXotc6Ks544z7LEA/TSbWdlAXtF2IGi22Ma8cy/nPT6uQTtYU0mggsqZTpz0dgixtA==; 5:boGYXhQuVL7H5GE7B33MudVCNG8kOE7EpDr5l/YXW88bKb/o8xQlKXtf8Bu9Ndjvmnpa1qRoyYiK+YgiGZt8L7llFKPM24mwwWk3HWwUzr9Pda3enbQciWHp4PfVyXdDJ5kpWhB2c1VA4zp/c3YtkMIZx8m8wPX4tpD+Ju9T7oA=; 7:gp/VMXNOUfUBtvR/u7WBMblUYdKCEc7k5Yf4gBGBXMxUKYCP1/H8KngyGvGbcb5ooEdpSho0+k/35ly5AgFyHGMJezVb7a8AqCz11u1bfwzK7xWLKB516HYbw92ppt5MMiUaPzpc2CmA2bfWXU8VHkNgOrS81oSK0aC196ocfD/9qqcUCjH7Fb+ytuKtLik4H+qmT/KvOjhX4ATQ6IZXMQh7+aROQH9ihmrzZOF9m74GSD9YU0gl7JE/r96hfAko x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f1d04439-8616-4a5c-5366-08d5edb64b6c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:DM5PR00MB0294; x-ms-traffictypediagnostic: DM5PR00MB0294: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3231311)(944501410)(52105095)(2018427008)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DM5PR00MB0294; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0294; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(346002)(366004)(39860400002)(53754006)(189003)(199004)(7736002)(33656002)(86612001)(11346002)(476003)(2906002)(110136005)(22452003)(6436002)(81166006)(86362001)(19609705001)(6246003)(446003)(39060400002)(486006)(7696005)(53936002)(14454004)(74316002)(6116002)(966005)(790700001)(186003)(229853002)(316002)(5250100002)(478600001)(72206003)(55016002)(10290500003)(6506007)(53546011)(105586002)(102836004)(256004)(106356001)(236005)(54896002)(99286004)(14444005)(46003)(8990500004)(8936002)(97736004)(9686003)(2900100001)(81156014)(8676002)(6306002)(5660300001)(76176011)(10090500001)(68736007)(606006)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0294; H:DM5PR00MB0296.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) x-microsoft-antispam-message-info: zduFaKJRWUO5oJ3mhLsQ33o32YplMO7LBseJ9gqA+ZLHwL2MNyKDMFZyg0/Bpzfsl6/vo/JCu6ERngWeIhjdYarTwKLWf8PobNjawK2iczVJEgFK0DNdISbRuFyctgh17gVTruQr+bH5oncE5yzLFJSfAPAQ/5tKcNGVM4JGCh9FJ3iQ4RCnQ4hrnENrrVQJ05nqQKwY7d9Em269whNgXo/RaZiE+EB0xaGB3MI7lcA4JjbNnkqm/Z4ysgXciFqZ07HWJdT4RwyTFBKHJv+qTHnwgSa2TccJPW/BzyESQA5US1aH1YV3E6JsfSF48NyO3oZ0XZbbYuN4Wi9St380w85pMwjPeDT29SPOTBmt6uA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0296804218028EEB46142372F5520DM5PR00MB0296namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1d04439-8616-4a5c-5366-08d5edb64b6c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 20:29:14.6353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0294 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:29:19 -0000 --_000_DM5PR00MB0296804218028EEB46142372F5520DM5PR00MB0296namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGFkb3B0aW9uLiAgVGhlIOKAnHJlc291cmNl4oCdIHJlcXVlc3QgcGFyYW1ldGVy IHRoYXQgaXQgZGVmaW5lcyBpcyBhbHJlYWR5IHdpZGVseSB1c2VkLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9t OiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFJpZmFhdCBTaGVr aC1ZdXNlZg0KU2VudDogVGh1cnNkYXksIEp1bHkgMTksIDIwMTggNDowMiBQTQ0KVG86IG9hdXRo IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb24g Zm9yICJSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAiDQoNCkhpIGFsbCwNCg0KVGhp cyBpcyB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb2YgdGhlICdSZXNvdXJjZSBJbmRpY2F0b3JzIGZv ciBPQXV0aCAyLjAnIGRvY3VtZW50DQpmb2xsb3dpbmcgdGhlIHBvc2l0aXZlIGNhbGwgZm9yIGFk b3B0aW9uIGF0IHRoZSBNb250cmVhbCBJRVRGIG1lZXRpbmcuDQoNCkhlcmUgaXMgdGhlIGRvY3Vt ZW50Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXJl c291cmNlLWluZGljYXRvcnMtMDINCg0KUGxlYXNlIGxldCB1cyBrbm93IGJ5IEF1Z3VzdCAybmQg d2hldGhlciB5b3UgYWNjZXB0IC8gb2JqZWN0IHRvIHRoZQ0KYWRvcHRpb24gb2YgdGhpcyBkb2N1 bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGluIHRoZSBPQXV0aA0Kd29ya2luZyBn cm91cC4NCg0KUmVnYXJkcywNClJpZmFhdA0K --_000_DM5PR00MB0296804218028EEB46142372F5520DM5PR00MB0296namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBzdXBwb3J0IGFkb3B0aW9uLiZuYnNwOyBUaGUg4oCc cmVzb3VyY2XigJ0gcmVxdWVzdCBwYXJhbWV0ZXIgdGhhdCBpdCBkZWZpbmVzIGlzIGFscmVhZHkg d2lkZWx5IHVzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBP ZiA8L2I+DQpSaWZhYXQgU2hla2gtWXVzZWY8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1 bHkgMTksIDIwMTggNDowMiBQTTxicj4NCjxiPlRvOjwvYj4gb2F1dGggJmx0O29hdXRoQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIENhbGwgZm9yIGFkb3B0aW9u IGZvciAmcXVvdDtSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAmcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5I aSBhbGwsPGJyPg0KPGJyPg0KVGhpcyBpcyB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb2YgdGhlICdS ZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAnIGRvY3VtZW50PGJyPg0KZm9sbG93aW5n IHRoZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlvbiBhdCB0aGUgTW9udHJlYWwgSUVURiBtZWV0 aW5nLjxicj4NCjxicj4NCkhlcmUgaXMgdGhlIGRvY3VtZW50Ojxicj4NCjwvc3Bhbj48YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3Vy Y2UtaW5kaWNhdG9ycy0wMiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOiMxMTU1Q0MiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1j YW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PGJyPg0KPGJyPg0KUGxlYXNlIGxldCB1cyBrbm93IGJ5IEF1 Z3VzdCAybmQgd2hldGhlciB5b3UgYWNjZXB0IC8gb2JqZWN0IHRvIHRoZTxicj4NCmFkb3B0aW9u IG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBpbiB0aGUgT0F1 dGg8YnI+DQp3b3JraW5nIGdyb3VwLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KUmlmYWF0PC9z cGFuPiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR00MB0296804218028EEB46142372F5520DM5PR00MB0296namp_-- From nobody Thu Jul 19 13:32:41 2018 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 F15CE130EF4 for ; Thu, 19 Jul 2018 13:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 DhXO-Z23Owgc for ; Thu, 19 Jul 2018 13:32:35 -0700 (PDT) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (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 B2E39130DFA for ; Thu, 19 Jul 2018 13:32:35 -0700 (PDT) Received: by mail-vk0-x244.google.com with SMTP id b78-v6so5035628vka.12 for ; Thu, 19 Jul 2018 13:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WNXhJajXnN1FTTlnu+X4hi1oDgoA8pExzW35r+OcMAw=; b=F26kMWtpBfw/QOA9ozh+rT8om6SBqlQ8bXmoK8KtPFazyhAnvU2yOJlSYPcni3/a9K 7wRL05iBMzL/XJQyS0b06IJ0wB3EBNACRSZpWP2Jq6xnqZruOFy0Z1FavnlJjrTkFtmy J4bcvxsP7NA3WfuxdKx+Bhr2aH/XB841X7KSzGQm9Z7cKYwivJz7EQEq11c4nKedfY0o L5kvzPALZPo/mhd2AotB44HnQf3IEICU95AaItnCoYwdg0OyeBEV44nB0T0kbT6MNpLk 8F+Tz2KWD+0XTQemmbMvUR38yviF2Q8sz1c2h9FKmGZoWaIeVDVl3A0dR/i2nXbxQCn+ H7UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WNXhJajXnN1FTTlnu+X4hi1oDgoA8pExzW35r+OcMAw=; b=SEAAOgh0OOGaNH/SRDjQ/z3Rn20f3A+iN+LNbNXiCdNrqUMuIOSbYhH8rGsM+qtQA5 lEBAHpkII5Lw2JWmYMmoHytJed3Y8J2eoL+250OWZJVKLCAnbmxjg/QYYk84sYUTloN3 /qvM9LpdtrvcjWHU/6dDsxbP01pCLv/HaT/fWBWyott4XsSwGdQ652xuEvzuqDdqL/TR PhKBPriPgUU9JMQZsoV1HD7+4ivW5QSUYF4FzKnrDKGX0HRWF03bgRINgiTnqElfoLRO YcW4TfvaLseFGx3En9/gVzdTsenpdT61GjZQG1KWlUb0Z1yU0KbrKh7tOpXna2+km0dn YszQ== X-Gm-Message-State: AOUpUlEj7uOKWe8hMiw7jiNG5uRvE5zNlHaK0jts0wIh5l2C2E6MgmXv qgk9PooyP3HwQ0ukD8OXkUWuezBKVVwJHxtwaJIDQQ== X-Google-Smtp-Source: AAOMgpc+ZC9IxCHHkorShgH1wq5bOkrQNxUMAh6L7shYlx1kctdumcEpRP18kKr9FS5nvGKtaq37NzvoAa8JlJgu0mA= X-Received: by 2002:a1f:a945:: with SMTP id s66-v6mr7183273vke.54.1532032354255; Thu, 19 Jul 2018 13:32:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:6383:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 13:32:13 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Thu, 19 Jul 2018 13:32:13 -0700 Message-ID: To: Mike Jones Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="000000000000434e51057160141e" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:32:39 -0000 --000000000000434e51057160141e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Question: if this is adopted along with https://datatracker.ietf. org/doc/draft-hardt-oauth-distributed/, is the plan for this spec to be the authoritative definition, and Distributed OAuth to take a reference instead of redefining? On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones wrote: > I support adoption. The =E2=80=9Cresource=E2=80=9D request parameter tha= t it defines is > already widely used. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * Rifaat Shekh-Yusef > *Sent:* Thursday, July 19, 2018 4:02 PM > *To:* oauth > *Subject:* [OAUTH-WG] Call for adoption for "Resource Indicators for > OAuth 2.0" > > > > Hi all, > > This is the call for adoption of the 'Resource Indicators for OAuth 2.0' > document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Regards, > Rifaat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000434e51057160141e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Question: if this is adopted along with=C2=A0https://datatracker.i= etf.org/doc/draft-hardt-oauth-distributed/, is the plan for t= his spec to be the authoritative definition, and Distributed OAuth to take = a reference instead of redefining?

On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I support adoption.=C2= =A0 The =E2=80=9Cresource=E2=80=9D request parameter that it defines is alr= eady widely used.

=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=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=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 -- Mike

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 4:02 PM
To: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] Call for adoption for "Resource Indicators = for OAuth 2.0"

=C2=A0

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat


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


--000000000000434e51057160141e-- From nobody Thu Jul 19 13:33:45 2018 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 905E0130F7F for ; Thu, 19 Jul 2018 13:33:37 -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 qDGHoSM4ZBdh for ; Thu, 19 Jul 2018 13:33:35 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 21188130EF4 for ; Thu, 19 Jul 2018 13:33:35 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id l25-v6so8165449ioh.12 for ; Thu, 19 Jul 2018 13:33:35 -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=74Hjlg/hhk7ywKgRPyYQg+t2V9CAh2kbQ74zXUjS5vA=; b=CUde/fn4gwWtbA03tyUi//rX/7dwoS6Gwxc2N9Qb5Vgmae12QasMfgubI4vFeq/ga9 9nPELtoRQ7U0Kp0c2jT1bMy8WPUJCWjuviCzueLVieg6Quqhbw+W7rzvDGmyk3wnjDwo fm/dGSo/h0I3Gz419tmb+AbNOjA6yxgqaOFD+k8w7JDlQbrJKqLrbiKdE7odN+4ZEexy SEcDe/sbqnOjrORP8gCIZhrdj2dIxLAhSobDY10WxzpTSYN0YXpf3R3ER7aYaU3pVyEv 6koay58XkPa249QgpzGUj9dbJhKPTDk+fbHgDP317c94WRjsWjKTbL0O8T0DpxYyHZbf nldg== 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=74Hjlg/hhk7ywKgRPyYQg+t2V9CAh2kbQ74zXUjS5vA=; b=WuE+nos5Sy2z3P1Mdc+TazsSlr5Z4NDikGZA+yPHYgGL7b4Ru9i+TI8p4lvT/tyaSQ Cq+BhmwU+dVnKAc2SOCp4cSv+olZg9G8FqrKSUaWLPuSlae3To4KJ9hyPefPZ4lLgmd5 tuTkq4gr5eUmGWtw/70sXCC/SKv29xwdz3NFqW8YLcyhR0wFPsu4CizEM6sJn6EUTqau AFPvnxroYCe2Sy4SvrPPWnloKwmkrDEdyh+50AdhJ3fc4prv7c+vu/LejDVeFfnTnFI0 razLXaZb2Xk3IRzqcZzUP+YLQuNKGWXo7y1UnVlD1DAN7h28nM4ycQXfPDDJwzxZJwWn SNAQ== X-Gm-Message-State: AOUpUlE/Qalg0KiFaKKdYe4mJf+qcsCmMNjP6KfckUX53/ufBz2P/jLY MhVQyAwGrZmaicH7FUo7h5Bck7OAvWgjvcBvJJE= X-Google-Smtp-Source: AA+uWPyfCj0ay1jeHr+6Qn7roN3yb+nEA7uJzdFnUTH7ulUYRAcwKikoD3X8FJb8hGoW59eL0flBaYDvUTRGQDrBEqw= X-Received: by 2002:a6b:410a:: with SMTP id n10-v6mr10371238ioa.0.1532032414450; Thu, 19 Jul 2018 13:33:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Thu, 19 Jul 2018 16:33:23 -0400 Message-ID: To: William Denniss Cc: Michael.Jones=40microsoft.com@dmarc.ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000d90828057160170f" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:33:42 -0000 --000000000000d90828057160170f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes On Thu, Jul 19, 2018 at 4:32 PM William Denniss wrote= : > Question: if this is adopted along with > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/, is the > plan for this spec to be the authoritative definition, and Distributed > OAuth to take a reference instead of redefining? > > On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > >> I support adoption. The =E2=80=9Cresource=E2=80=9D request parameter th= at it defines is >> already widely used. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of * Rifaat Shekh-Yuse= f >> *Sent:* Thursday, July 19, 2018 4:02 PM >> *To:* oauth >> *Subject:* [OAUTH-WG] Call for adoption for "Resource Indicators for >> OAuth 2.0" >> >> >> >> Hi all, >> >> This is the call for adoption of the 'Resource Indicators for OAuth 2.0' >> document >> following the positive call for adoption at the Montreal IETF meeting. >> >> Here is the document: >> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 >> >> Please let us know by August 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >> >> Regards, >> Rifaat >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --000000000000d90828057160170f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes

O= n Thu, Jul 19, 2018 at 4:32 PM William Denniss <wdenniss@google.com> wrote:
Question: if this is adopted along with=C2= =A0https= ://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/, is the plan= for this spec to be the authoritative definition, and Distributed OAuth to= take a reference instead of redefining?

=
On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I support adoption.=C2= =A0 The =E2=80=9Cresource=E2=80=9D request parameter that it defines is alr= eady widely used.

=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=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=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 -- Mike

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 4:02 PM
To: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] Call for adoption for "Resource Indicators = for OAuth 2.0"

=C2=A0

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-= 02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat


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


--000000000000d90828057160170f-- From nobody Thu Jul 19 13:35:00 2018 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 EA637130FC1 for ; Thu, 19 Jul 2018 13:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 LcEiiVyXcRma for ; Thu, 19 Jul 2018 13:34:48 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0067.outbound.protection.outlook.com [104.47.0.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFAB130DFA for ; Thu, 19 Jul 2018 13:34:47 -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=jXRJaPEzbJKltAX/sO8aDlQJQHhQae1zdpvltqkCmBM=; b=jsdUO5dVi5HVs9ybwVnIiOps3R6aHThkekhTt6l6ewpsdcEcR9QulaqDE+WaxYl1yjo/g91+iKc03oTNrmTPquqeoZkV/DCfwsPl08WVVd7sXSffS8RUyvkRStGTDN8fDxdqe5pkEEeKsyRMUgXkx+jan+OuktG8YDEHODLgDpA= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1311.eurprd08.prod.outlook.com (10.167.197.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.21; Thu, 19 Jul 2018 20:34:44 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Thu, 19 Jul 2018 20:34:44 +0000 From: Hannes Tschofenig To: William Denniss , Mike Jones CC: oauth Thread-Topic: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" Thread-Index: AQHUH5tpWfx6ee5zikCyGLNHikwcWqSW/xoAgAAA1YCAAACHUA== Date: Thu, 19 Jul 2018 20:34:44 +0000 Message-ID: References: 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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1311; 7:cfuRDCaIm3vQzVD7V1xTzX09r5xiqu8m/D7tcU6mgZCgb3C4p/ZiiCU4CYWeXi0/6fXDP9ckV9+FGToLHr8O7UNCB64vmKM4Uv9oXmy6rIQEF2RLArN7dSeBib7r5xxkAC3mLLtee5+qgAqGLYYO7zH7uREXg1iCIg33ZaKbQuZJgiO5Xp3y7qdcbdH/BSHR2y0LGHfNTYdBXYf2LYSZnx+0MSZWOoqUD4HtQF5pIj8ZfwuIxR+36ZBf0Ny0P2j7 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 037eeeef-dbc2-475a-a8fc-08d5edb70fbd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1311; x-ms-traffictypediagnostic: VI1PR0801MB1311: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(223705240517415)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1311; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1311; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(376002)(136003)(346002)(53754006)(189003)(199004)(40434004)(966005)(33656002)(97736004)(2900100001)(790700001)(66066001)(236005)(6306002)(106356001)(105586002)(14454004)(3846002)(6116002)(9686003)(72206003)(6436002)(229853002)(54896002)(55016002)(478600001)(606006)(26005)(4326008)(86362001)(2906002)(76176011)(8676002)(7736002)(9326002)(316002)(53546011)(186003)(74316002)(11346002)(8936002)(81166006)(446003)(110136005)(7696005)(53936002)(5660300001)(68736007)(476003)(6506007)(81156014)(14444005)(256004)(486006)(5250100002)(99286004)(5024004)(25786009)(6246003)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1311; 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-microsoft-antispam-message-info: zIyFHt64RqTVgu68dNsPtHeV5/I+If3q7Ox7U0aAb6KK9sXeg/z5++/oHHTZwOYozZE4bdtE91QFqCRUn9WDYMcJL/asgGhQQ7b+lThwKK4Mz4TuMUipRqVcnb0XqeMcM815jXb0PQ1MgMDyKFueucu5AIcuInes0mxMygCzbvYkmXGFucxszq5v0dCGHlbiH+V69XXfhPw+50blJA6MAzPlvmmPrQOvxwl/l9/u8FBTZoXTzy5TuFj1v8OWes9y2/ixeajkag9sE1h1GhkUBiRTIqOj+4D7kkgnWyIB4xl19OIStMXSah3lSNK62997ZhWoudSn44uJAPKdkDfDmzih5vlaDzfuq57NIhHpsl0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112EDA04FB2A57F2CF6CA5CFA520VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 037eeeef-dbc2-475a-a8fc-08d5edb70fbd X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 20:34:44.0518 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1311 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:34:57 -0000 --_000_VI1PR0801MB2112EDA04FB2A57F2CF6CA5CFA520VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2lsbGlhbSwNCg0KdGhhdCB3YXMgdGhlIGlkZWEuDQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9t OiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXaWxs aWFtIERlbm5pc3MNClNlbnQ6IDE5IEp1bHkgMjAxOCAxNjozMg0KVG86IE1pa2UgSm9uZXMNCkNj OiBvYXV0aA0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb24gZm9yICJS ZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAiDQoNClF1ZXN0aW9uOiBpZiB0aGlzIGlz IGFkb3B0ZWQgYWxvbmcgd2l0aCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1oYXJkdC1vYXV0aC1kaXN0cmlidXRlZC8sIGlzIHRoZSBwbGFuIGZvciB0aGlzIHNwZWMgdG8g YmUgdGhlIGF1dGhvcml0YXRpdmUgZGVmaW5pdGlvbiwgYW5kIERpc3RyaWJ1dGVkIE9BdXRoIHRv IHRha2UgYSByZWZlcmVuY2UgaW5zdGVhZCBvZiByZWRlZmluaW5nPw0KDQpPbiBUaHUsIEp1bCAx OSwgMjAxOCBhdCAxOjI5IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0 LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21A ZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkkgc3VwcG9ydCBhZG9wdGlvbi4gIFRoZSDigJxyZXNv dXJjZeKAnSByZXF1ZXN0IHBhcmFtZXRlciB0aGF0IGl0IGRlZmluZXMgaXMgYWxyZWFkeSB3aWRl bHkgdXNlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgUmlmYWF0IFNoZWto LVl1c2VmDQpTZW50OiBUaHVyc2RheSwgSnVseSAxOSwgMjAxOCA0OjAyIFBNDQpUbzogb2F1dGgg PG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbT0FVVEgt V0ddIENhbGwgZm9yIGFkb3B0aW9uIGZvciAiUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGgg Mi4wIg0KDQpIaSBhbGwsDQoNClRoaXMgaXMgdGhlIGNhbGwgZm9yIGFkb3B0aW9uIG9mIHRoZSAn UmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4wJyBkb2N1bWVudA0KZm9sbG93aW5nIHRo ZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlvbiBhdCB0aGUgTW9udHJlYWwgSUVURiBtZWV0aW5n Lg0KDQpIZXJlIGlzIHRoZSBkb2N1bWVudDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyDQoNClBsZWFzZSBsZXQg dXMga25vdyBieSBBdWd1c3QgMm5kIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGUN CmFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBp biB0aGUgT0F1dGgNCndvcmtpbmcgZ3JvdXAuDQoNClJlZ2FyZHMsDQpSaWZhYXQNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcg bGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUg Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp YWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9y IGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVk aXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB2112EDA04FB2A57F2CF6CA5CFA520VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFdpbGxpYW0sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoYXQgd2FzIHRo ZSBpZGVhLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaWFvPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhhbm5lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPldpbGxpYW0g RGVubmlzczxicj4NCjxiPlNlbnQ6PC9iPiAxOSBKdWx5IDIwMTggMTY6MzI8YnI+DQo8Yj5Ubzo8 L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIGFkb3B0aW9uIGZvciAmcXVvdDtSZXNvdXJjZSBJbmRp Y2F0b3JzIGZvciBPQXV0aCAyLjAmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5RdWVzdGlvbjogaWYgdGhpcyBpcyBhZG9wdGVkIGFsb25nIHdpdGgmbmJzcDs8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJkdC1vYXV0aC1k aXN0cmlidXRlZC8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2NvbG9yOiMxMTU1Q0MiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhh cmR0LW9hdXRoLWRpc3RyaWJ1dGVkLzwvc3Bhbj48L2E+LA0KIGlzIHRoZSBwbGFuIGZvciB0aGlz IHNwZWMgdG8gYmUgdGhlIGF1dGhvcml0YXRpdmUgZGVmaW5pdGlvbiwgYW5kIERpc3RyaWJ1dGVk IE9BdXRoIHRvIHRha2UgYSByZWZlcmVuY2UgaW5zdGVhZCBvZiByZWRlZmluaW5nPzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDE5LCAyMDE4IGF0IDE6 MjkgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzPTQwbWlj cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXM9 NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIHN1cHBvcnQgYWRvcHRpb24uJm5ic3A7IFRoZSDi gJxyZXNvdXJjZeKAnSByZXF1ZXN0IHBhcmFtZXRlciB0aGF0IGl0IGRlZmluZXMgaXMgYWxyZWFk eSB3aWRlbHkgdXNlZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gT0F1dGggJmx0OzxhIGhyZWY9Im1haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJpZmFhdCBTaGVraC1ZdXNlZjxi cj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxOSwgMjAxOCA0OjAyIFBNPGJyPg0KPGI+ VG86PC9iPiBvYXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FV VEgtV0ddIENhbGwgZm9yIGFkb3B0aW9uIGZvciAmcXVvdDtSZXNvdXJjZSBJbmRpY2F0b3JzIGZv ciBPQXV0aCAyLjAmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5IaSBhbGwsPGJyPg0KPGJyPg0KVGhpcyBpcyB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb2Yg dGhlICdSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAnIGRvY3VtZW50PGJyPg0KZm9s bG93aW5nIHRoZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlvbiBhdCB0aGUgTW9udHJlYWwgSUVU RiBtZWV0aW5nLjxicj4NCjxicj4NCkhlcmUgaXMgdGhlIGRvY3VtZW50Ojxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJj ZS1pbmRpY2F0b3JzLTAyIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1 Q0MiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNv dXJjZS1pbmRpY2F0b3JzLTAyPC9zcGFuPjwvYT48YnI+DQo8YnI+DQpQbGVhc2UgbGV0IHVzIGtu b3cgYnkgQXVndXN0IDJuZCB3aGV0aGVyIHlvdSBhY2NlcHQgLyBvYmplY3QgdG8gdGhlPGJyPg0K YWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGlu IHRoZSBPQXV0aDxicj4NCndvcmtpbmcgZ3JvdXAuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpS aWZhYXQgPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0u IFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR0801MB2112EDA04FB2A57F2CF6CA5CFA520VI1PR0801MB2112_-- From nobody Thu Jul 19 13:40:07 2018 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 EB324131055 for ; Thu, 19 Jul 2018 13:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 qjdt46uR04qS for ; Thu, 19 Jul 2018 13:40:01 -0700 (PDT) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::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 1BE3C130FA0 for ; Thu, 19 Jul 2018 13:39:58 -0700 (PDT) Received: by mail-vk0-x243.google.com with SMTP id l143-v6so5070939vke.1 for ; Thu, 19 Jul 2018 13:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Svj84kDklaZ09aN3QY9Ftsd12danvhfH+olpMS7uNK4=; b=CsBJF6I2OGV8MM8AYwbp7/FA1WsnkdGwhMMzlS/TSHhUTKIogCZ/DWRgqlBJyU/RTZ T62RTDObgtR+ilXYZzrBK0u+eLJpWhYoS3Rlkk3FgtAU7Rz/Hs0+c9+kWAu6e0/cMeF5 OLlDYwBbl9fue0vSnH8+cTd+8G29dFJrZc5A4i88XqBq3EC5ab9bbMeZFsAWiGGi3lps 8Ks/rbLrl9pdyxOTY2rhy/obk43JeXMaOo1jh2MgeeLbxScT4rfcnRZEpbxqtR6vQpiE yjiWw7NomX7n/2fM/dNr0Gi8hAQHUAWhpOKkvypYyxmnM5rvbjxUMH3HY+Ub5In2KNHQ v1cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Svj84kDklaZ09aN3QY9Ftsd12danvhfH+olpMS7uNK4=; b=dC9quKOQuFTRHr6sqbPOQVdEBZD+OX1W9aofGQhyG1o7a7HmQa1bL+bNxu/5y01y8o cAfDBZLDZa5jXmvPGnGGVfHVam4gXLJ0nwsmyEPCq5LNREEWlhz0GI7B3dALY35xse1e SuqBDKy5ExoGZMUKj7+KycaiDttP0kXQLvulhlfYZbms0QBkOXZLeo80svEv0XfShs/h Maf8HXaslDaNsEpOvIsH7WsVAzKvQoyGsbXEugqsqQ2KlokcCc48kx8rhLG1e43Juqqw qz5x2L6DkvXpdJ6wdXF5XP+O6fxgQEMgU5qLe1gTBHSgOaLvbcfBVOic8yXNg1fRQCfn l0vA== X-Gm-Message-State: AOUpUlEsAuRFnAB4V7mKRYMiql+Aa3WV4+mP8xs9rtVA8ozDkgDH0rVi FLnLcnKcPf9Ni1OXqfQ+MpE1AZINMhgAeBFSdPyyTJj1 X-Google-Smtp-Source: AAOMgpejyjP7AFbMLnEXyuTSfauqBHCVtnbIcMyEohpDDbfgZUvOJuelUJMiEJXKVqC0jZyoG3EP0frfqVF+OCi7Jgo= X-Received: by 2002:a1f:5981:: with SMTP id n123-v6mr7254958vkb.43.1532032796690; Thu, 19 Jul 2018 13:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:6383:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 13:39:36 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Thu, 19 Jul 2018 13:39:36 -0700 Message-ID: To: Hannes Tschofenig Cc: Mike Jones , oauth Content-Type: multipart/alternative; boundary="000000000000a23ea90571602ecc" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:40:05 -0000 --000000000000a23ea90571602ecc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks! I assume then that there are use-cases for this that are outside the Distributed OAuth use-case? Did we document them? I'm supportive (of both drafts), but think we should get the rationale on the record since the option to incorporate this spec in Distributed OAuth was raised in the meeting. On Thu, Jul 19, 2018 at 1:34 PM, Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Hi William, > > > > that was the idea. > > > > Ciao > > Hannes > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William > Denniss > *Sent:* 19 July 2018 16:32 > *To:* Mike Jones > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for > OAuth 2.0" > > > > Question: if this is adopted along with https://datatracker.ietf. > org/doc/draft-hardt-oauth-distributed/, is the plan for this spec to be > the authoritative definition, and Distributed OAuth to take a reference > instead of redefining? > > > > On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones com@dmarc.ietf.org> wrote: > > I support adoption. The =E2=80=9Cresource=E2=80=9D request parameter tha= t it defines is > already widely used. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *Rifaat Shekh-Yusef > *Sent:* Thursday, July 19, 2018 4:02 PM > *To:* oauth > *Subject:* [OAUTH-WG] Call for adoption for "Resource Indicators for > OAuth 2.0" > > > > Hi all, > > This is the call for adoption of the 'Resource Indicators for OAuth 2.0' > document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Regards, > Rifaat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > 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. > --000000000000a23ea90571602ecc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks! I assume then that there are use-cases for this th= at are outside the Distributed OAuth use-case? Did we document them?=C2=A0 = I'm supportive (of both drafts), but think we should get the rationale = on the record since the option to incorporate this spec in Distributed OAut= h was raised in the meeting.


On Thu, Jul 19, 2018 at 1:34 PM, Hannes Tsc= hofenig <Hannes.Tschofenig@arm.com> wrote:

Hi William,

=C2=A0

that was the idea.

=C2=A0

Ciao=

Hannes

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of William Denniss
Sent: 19 July 2018 16:32
To: Mike Jones
Cc: oauth
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicat= ors for OAuth 2.0"

=C2=A0

Question: if this is adopted along with=C2=A0https://datatrack= er.ietf.org/doc/draft-hardt-oauth-distributed/, is the plan for this spec to be the authoritative definition, and Distribu= ted OAuth to take a reference instead of redefining?

=C2=A0

On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:<= /u>

I suppo= rt adoption.=C2=A0 The =E2=80=9Cresource=E2=80=9D request parameter that it= defines is already widely used.<= /span>

=C2=A0<= /span>

=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=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=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 -- Mike<= /span>

=C2=A0<= /span>

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 4:02 PM
To: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] Call for adoption for "Resource Indicators = for OAuth 2.0"

=C2=A0

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf= .org/html/draft-campbell-oauth-resource-indicators-02<= br>
Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat


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

=C2=A0

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.

--000000000000a23ea90571602ecc-- From nobody Thu Jul 19 13:53:17 2018 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 9EFDE130E30 for ; Thu, 19 Jul 2018 13:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 YJcfHKfnO6Js for ; Thu, 19 Jul 2018 13:53:08 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640104.outbound.protection.outlook.com [40.107.64.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3EE130EF4 for ; Thu, 19 Jul 2018 13:53:07 -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=SJ7/dEeOIYHlnd1YtLElrSYHxGojlAIRTJ6WZq8fbZo=; b=RtJwkqg1i7jQGjkankbyCyHyH+wRew5by2eR9OegaJAygKQAO8JAxIFJ3+dkVKN9fvGg3D8+dF/CRtEBov+0V3FcDYE53b5Ww6u45WRLCOiIzgmJyjtiSblbaBtHRd6xIIndJUN+b0xnMLA6IwhLze6sRBiqnoc0HIFlYCXo/JM= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (52.132.128.37) by DM5PR00MB0438.namprd00.prod.outlook.com (52.132.129.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1016.0; Thu, 19 Jul 2018 20:53:05 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::ccd4:2ea:171a:e326]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::ccd4:2ea:171a:e326%8]) with mapi id 15.20.1017.000; Thu, 19 Jul 2018 20:53:05 +0000 From: Mike Jones To: William Denniss , Hannes Tschofenig CC: oauth Thread-Topic: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" Thread-Index: AQHUH5tpAEJtgz4Ml0eD0vJ2JOwxQKSW/s9QgAABIICAAAC0AIAAAVwAgAADBoA= Date: Thu, 19 Jul 2018 20:53:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1232:144:a03e:93f:7764:5cc7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0438; 6:ZeHFcapLe6sw7mzoK/d7FkhH+aCuq91HmaXi4AjR/RsBamHBVGXbL8izzYsBmUi6C3j0/0Z/RMLVh2RVGR5cFZAf8aGIRHAX9x3uknszoH5p59fmqrvHxqEaLIToszzZr9u2xUZHbSnouUPY8bQIknQ6L8E3CeD56qXFcpIr60gM+kwNXoa9eW3dDD+kDDMIEpA6MHAANCXOnbSvV6TeKljDDwCs1kX1JL8MIqEewett/EdmNsQz3C4MSH26cCQCn+HZGZzfAmVH679TB5jzgvJOGHYutLrOBFRmqW/ENcb6s0HVgPoKxJE8t6DDJeJrxNUvrZVn1zP/q7s2hV3fXpZlAQkTSSL8B9UMM//A26T/+h8Feoa2D0uW5HbjVDeWGzf63jJZDMKK4o6UMHQJ32xLnnCtjRo1u96O25Ukpq+nQqf4EN19BR9XhN1XK9JVBf/IxVPZ63rrXzHAHs2foA==; 5:JpdwytQfemf1caCDkEQZ1zLBftb/JymD3DawC5mHKOMJfexTAlL5YfnYpuv4hOWyyVYqtjiu3ClIwnZoTZYe/gSBgzCdEldy/p1yh24CYt7CsUATbT47hE78VE5KTw/rA/TYV8S4Q1Yen13kq/A8Eh85pJWNeWhJz0xyPkUYyoU=; 7:+captnx9NtS5oA0gAf89iC3ok3nOonoEwFuq7ul1jxpYDKmq4ldNoVtvaY36kOHahKRL+6fBHGxkjhKaEzdDB8YTJWsbTl5Ts0cOS9Qzx5b0PUDc0RmxItkl94eATPRDXkAwUIk+KgjhxgGvNIcAapBp/UPYGhAdRadD6IxPHwcLiNdzXjVHPOHNZKuKBdYQAMfbaxWmMhP9yyRkDbrm8iF2sFhfAANOS4i7PGu8nS3KK3vUDdKdvimOmWyysgwD x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7b86224c-7efc-463a-f9ad-08d5edb9a05c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600067)(711020)(4618075)(2017052603328)(7193020); SRVR:DM5PR00MB0438; x-ms-traffictypediagnostic: DM5PR00MB0438: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(180628864354917)(89211679590171)(120809045254105)(223705240517415)(211936372134217)(153496737603132)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(2018427008)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DM5PR00MB0438; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0438; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(366004)(346002)(376002)(40434004)(189003)(199004)(53754006)(68736007)(22452003)(93886005)(110136005)(606006)(8936002)(81166006)(81156014)(316002)(6246003)(790700001)(6116002)(8676002)(19609705001)(53936002)(7736002)(99286004)(10090500001)(229853002)(54896002)(55016002)(6436002)(8990500004)(6306002)(74316002)(236005)(97736004)(2906002)(9686003)(86362001)(105586002)(186003)(53546011)(76176011)(486006)(106356001)(6506007)(86612001)(476003)(11346002)(33656002)(446003)(10290500003)(4326008)(966005)(25786009)(46003)(478600001)(14454004)(72206003)(5660300001)(14444005)(5024004)(256004)(2900100001)(7696005)(102836004)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0438; H:DM5PR00MB0296.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) x-microsoft-antispam-message-info: 1viMcbXRN8PFdR5zXqJkmfkRJA/P9W/amSolQuxm1++CWzEs0gpJJrXID8fiqrkWiWJTXe2vBQaBfKq1mtx41kXeFkNR+v7NMN6Wn8Pa5MCoeBeV/1NrbAU1bPfVmFyKxIszrud0fJOgRLUI19omSniKBBbNJVxnlNdamjW7Nh3RP3zUV+tca0pT0Ta0wqu8lARdy4rIzbupoJm/DibSnDtI1RwdDBT4KH8SWKpk6shuaN03c+GAGkbcAbrVib2hE7saeHb7kJgp8txzjhMvhUtDnMHM3dGQ8GyOj1Fn4B0JwrX6AWQ+GKU6WgFPD4W/4uOkhGpZbLJwa7NKazvE1kUb3ohkBtRGPJfcWtvJ9Z8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB02967D18645764A7E598B4EFF5520DM5PR00MB0296namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b86224c-7efc-463a-f9ad-08d5edb9a05c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 20:53:05.6452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0438 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:53:12 -0000 --_000_DM5PR00MB02967D18645764A7E598B4EFF5520DM5PR00MB0296namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWljcm9zb2Z04oCZcyBBenVyZSBBRCBPQXV0aCBzZXJ2ZXIgaGFzIHVzZWQgdGhlIHJlc291cmNl PSBwYXJhbWV0ZXIgc2luY2UgYXQgbGVhc3QgMjAxMiB0byBpbmRpY2F0ZSB3aGF0IHJlc291cmNl IHRoZSByZXF1ZXN0ZWQgYWNjZXNzIHRva2VuIGlzIHRvIGJlIGZvci4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJv bTogV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPg0KU2VudDogVGh1cnNkYXks IEp1bHkgMTksIDIwMTggNDo0MCBQTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNj aG9mZW5pZ0Bhcm0uY29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT47IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENh bGwgZm9yIGFkb3B0aW9uIGZvciAiUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4wIg0K DQpUaGFua3MhIEkgYXNzdW1lIHRoZW4gdGhhdCB0aGVyZSBhcmUgdXNlLWNhc2VzIGZvciB0aGlz IHRoYXQgYXJlIG91dHNpZGUgdGhlIERpc3RyaWJ1dGVkIE9BdXRoIHVzZS1jYXNlPyBEaWQgd2Ug ZG9jdW1lbnQgdGhlbT8gIEknbSBzdXBwb3J0aXZlIChvZiBib3RoIGRyYWZ0cyksIGJ1dCB0aGlu ayB3ZSBzaG91bGQgZ2V0IHRoZSByYXRpb25hbGUgb24gdGhlIHJlY29yZCBzaW5jZSB0aGUgb3B0 aW9uIHRvIGluY29ycG9yYXRlIHRoaXMgc3BlYyBpbiBEaXN0cmlidXRlZCBPQXV0aCB3YXMgcmFp c2VkIGluIHRoZSBtZWV0aW5nLg0KDQoNCk9uIFRodSwgSnVsIDE5LCAyMDE4IGF0IDE6MzQgUE0s IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5u ZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4gd3JvdGU6DQpIaSBXaWxsaWFtLA0KDQp0aGF0IHdhcyB0 aGUgaWRlYS4NCg0KQ2lhbw0KSGFubmVzDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBXaWxsaWFtIERlbm5pc3MNClNlbnQ6IDE5IEp1bHkgMjAxOCAxNjozMg0KVG86IE1pa2UgSm9u ZXMNCkNjOiBvYXV0aA0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb24g Zm9yICJSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAiDQoNClF1ZXN0aW9uOiBpZiB0 aGlzIGlzIGFkb3B0ZWQgYWxvbmcgd2l0aCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1oYXJkdC1vYXV0aC1kaXN0cmlidXRlZC8sIGlzIHRoZSBwbGFuIGZvciB0aGlzIHNw ZWMgdG8gYmUgdGhlIGF1dGhvcml0YXRpdmUgZGVmaW5pdGlvbiwgYW5kIERpc3RyaWJ1dGVkIE9B dXRoIHRvIHRha2UgYSByZWZlcmVuY2UgaW5zdGVhZCBvZiByZWRlZmluaW5nPw0KDQpPbiBUaHUs IEp1bCAxOSwgMjAxOCBhdCAxOjI5IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWlj cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86TWljaGFlbC5Kb25lcz00MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkkgc3VwcG9ydCBhZG9wdGlvbi4gIFRoZSDi gJxyZXNvdXJjZeKAnSByZXF1ZXN0IHBhcmFtZXRlciB0aGF0IGl0IGRlZmluZXMgaXMgYWxyZWFk eSB3aWRlbHkgdXNlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgUmlmYWF0 IFNoZWtoLVl1c2VmDQpTZW50OiBUaHVyc2RheSwgSnVseSAxOSwgMjAxOCA0OjAyIFBNDQpUbzog b2F1dGggPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBb T0FVVEgtV0ddIENhbGwgZm9yIGFkb3B0aW9uIGZvciAiUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3Ig T0F1dGggMi4wIg0KDQpIaSBhbGwsDQoNClRoaXMgaXMgdGhlIGNhbGwgZm9yIGFkb3B0aW9uIG9m IHRoZSAnUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4wJyBkb2N1bWVudA0KZm9sbG93 aW5nIHRoZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlvbiBhdCB0aGUgTW9udHJlYWwgSUVURiBt ZWV0aW5nLg0KDQpIZXJlIGlzIHRoZSBkb2N1bWVudDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyDQoNClBsZWFz ZSBsZXQgdXMga25vdyBieSBBdWd1c3QgMm5kIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0 byB0aGUNCmFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Ig d29yayBpbiB0aGUgT0F1dGgNCndvcmtpbmcgZ3JvdXAuDQoNClJlZ2FyZHMsDQpSaWZhYXQNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBh bnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCg== --_000_DM5PR00MB02967D18645764A7E598B4EFF5520DM5PR00MB0296namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+TWljcm9zb2Z04oCZcyBBenVyZSBB RCBPQXV0aCBzZXJ2ZXIgaGFzIHVzZWQgdGhlIHJlc291cmNlPSBwYXJhbWV0ZXIgc2luY2UgYXQg bGVhc3QgMjAxMiB0byBpbmRpY2F0ZSB3aGF0IHJlc291cmNlIHRoZSByZXF1ZXN0ZWQgYWNjZXNz IHRva2VuIGlzIHRvIGJlIGZvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBXaWxsaWFtIERlbm5pc3MgJmx0O3dkZW5uaXNzQGdvb2dsZS5jb20mZ3Q7 IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxOSwgMjAxOCA0OjQwIFBNPGJyPg0K PGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbSZndDs7IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb24gZm9yICZxdW90O1Jlc291cmNl IEluZGljYXRvcnMgZm9yIE9BdXRoIDIuMCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzISBJIGFzc3VtZSB0aGVuIHRoYXQgdGhlcmUgYXJlIHVzZS1jYXNlcyBmb3Ig dGhpcyB0aGF0IGFyZSBvdXRzaWRlIHRoZSBEaXN0cmlidXRlZCBPQXV0aCB1c2UtY2FzZT8gRGlk IHdlIGRvY3VtZW50IHRoZW0/Jm5ic3A7IEknbSBzdXBwb3J0aXZlIChvZiBib3RoIGRyYWZ0cyks IGJ1dCB0aGluayB3ZSBzaG91bGQgZ2V0IHRoZSByYXRpb25hbGUgb24gdGhlIHJlY29yZCBzaW5j ZSB0aGUgb3B0aW9uIHRvIGluY29ycG9yYXRlDQogdGhpcyBzcGVjIGluIERpc3RyaWJ1dGVkIE9B dXRoIHdhcyByYWlzZWQgaW4gdGhlIG1lZXRpbmcuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDE5LCAyMDE4IGF0IDE6MzQgUE0sIEhh bm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJt LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5I aSBXaWxsaWFtLA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+dGhhdCB3YXMgdGhlIGlkZWEuDQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEg bmFtZT0ibV8tOTA3MTI0OTkxMjExNDU2NDUyX19NYWlsRW5kQ29tcG9zZSI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6bV8tOTA3MTI0OTkxMjExNDU2NDUyX19NYWlsRW5kQ29tcG9zZSI+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2lh bzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi Pkhhbm5lczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5XaWxsaWFtIERlbm5pc3M8YnI+DQo8Yj5TZW50 OjwvYj4gMTkgSnVseSAyMDE4IDE2OjMyPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0K PGI+Q2M6PC9iPiBvYXV0aDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBDYWxs IGZvciBhZG9wdGlvbiBmb3IgJnF1b3Q7UmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4w JnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIj5RdWVzdGlvbjogaWYgdGhpcyBpcyBhZG9wdGVkIGFsb25nIHdp dGgmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1o YXJkdC1vYXV0aC1kaXN0cmlidXRlZC8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0O2NvbG9yOiMxMTU1Q0MiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWhhcmR0LW9hdXRoLWRpc3RyaWJ1dGVkLzwvc3Bhbj48L2E+LA0KIGlzIHRoZSBw bGFuIGZvciB0aGlzIHNwZWMgdG8gYmUgdGhlIGF1dGhvcml0YXRpdmUgZGVmaW5pdGlvbiwgYW5k IERpc3RyaWJ1dGVkIE9BdXRoIHRvIHRha2UgYSByZWZlcmVuY2UgaW5zdGVhZCBvZiByZWRlZmlu aW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gVGh1LCBKdWwgMTks IDIwMTggYXQgMToyOSBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwu Sm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TWlj aGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ow0KIHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBzdXBwb3J0IGFkb3B0aW9uLiZuYnNw OyBUaGUg4oCccmVzb3VyY2XigJ0gcmVxdWVzdCBwYXJhbWV0ZXIgdGhhdCBpdCBkZWZpbmVzIGlz IGFscmVhZHkgd2lkZWx5IHVzZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+RnJvbTo8L2I+IE9BdXRoICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+ T24gQmVoYWxmIE9mIDwvYj5SaWZhYXQgU2hla2gtWXVzZWY8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEp1bHkgMTksIDIwMTggNDowMiBQTTxicj4NCjxiPlRvOjwvYj4gb2F1dGggJmx0Ozxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBDYWxsIGZvciBhZG9w dGlvbiBmb3IgJnF1b3Q7UmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4wJnF1b3Q7PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgYWxsLDxicj4NCjxi cj4NClRoaXMgaXMgdGhlIGNhbGwgZm9yIGFkb3B0aW9uIG9mIHRoZSAnUmVzb3VyY2UgSW5kaWNh dG9ycyBmb3IgT0F1dGggMi4wJyBkb2N1bWVudDxicj4NCmZvbGxvd2luZyB0aGUgcG9zaXRpdmUg Y2FsbCBmb3IgYWRvcHRpb24gYXQgdGhlIE1vbnRyZWFsIElFVEYgbWVldGluZy48YnI+DQo8YnI+ DQpIZXJlIGlzIHRoZSBkb2N1bWVudDo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMiIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMTE1NUNDIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMjwv c3Bhbj48L2E+PGJyPg0KPGJyPg0KUGxlYXNlIGxldCB1cyBrbm93IGJ5IEF1Z3VzdCAybmQgd2hl dGhlciB5b3UgYWNjZXB0IC8gb2JqZWN0IHRvIHRoZTxicj4NCmFkb3B0aW9uIG9mIHRoaXMgZG9j dW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBpbiB0aGUgT0F1dGg8YnI+DQp3b3Jr aW5nIGdyb3VwLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KUmlmYWF0IDxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5JTVBPUlRB TlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkNCiB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBw ZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9y bWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR00MB02967D18645764A7E598B4EFF5520DM5PR00MB0296namp_-- From nobody Thu Jul 19 13:54:40 2018 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 4D43E130FC2 for ; Thu, 19 Jul 2018 13:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 3SH7FwzVtDCy for ; Thu, 19 Jul 2018 13:54:27 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 78513130F43 for ; Thu, 19 Jul 2018 13:54:27 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id g141-v6so9447750ita.4 for ; Thu, 19 Jul 2018 13:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=WQH5iosvx73+6oYkOMCi1h7AYl7qycPmH77AGYulX2o=; b=DvwywZOhuBDOgYXVDdgVLRjnfzor1ow1j6miyYjMU2EaevKRiNjD7hV68fTZ8c3S0/ 2eEHm7rAZnmihiuJiGJ6RjPPPtQyQ1up4MBrUyfCs0TCY/syFHQMOBuaO1VvW89TQqE+ hlNaayQz91oBkJPIA+IDSvnE/WW9o25tjy5NmX7A5IWb9/ma1lLsbQtTL/TWprd5tEg7 Xub4c1Jh8W56jdMtNlJEKpjQHMcdx4WwAJm/dTDbtxJPuyCnkDU15tN5yZS4FLQOj5jl ns3DOOQp4E1+UQDhzenHHcvbBsjF4uYVJPEPRpmf0Yv6ND+JBWnlCE2vgMIRiyTenstD BoAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=WQH5iosvx73+6oYkOMCi1h7AYl7qycPmH77AGYulX2o=; b=XnwhOhoU/3856NNOiKxaBW4y7NF8y3kMWLL775LzsjMaCnYy/2hiIhWbDxM+11b9Di N3sjf/fwQy9CLtiSTwSRo378fl5mvSVvO/zk4vNNyMmQq6CimgpgvY+25k/K+OfFjIk0 HNfSaYvfCFZBHVwMuxe7W3/9QLhCPFXtdGpskp156zFnhoc+jeGEv0vFTgQ4Dz2jX5jg iDwQ0Gqh+SLvt3SLlIBukPYoMorB+9zD98DZjStkEPpOACObfXXGpv2ONCpogr4k+viD diyJqLN2dPnPZb+z6P1e7NpTDhR5RFPvKQOMTlqjo4EzJS6YU7hNMV0SnN6hClPxPpgL CA7g== X-Gm-Message-State: AOUpUlHh1fB7LDM8wB0EobHhoHfbFpd+scFLoLqQe4zUdBYU+gkr9khY Z+pNWFrT7zCkRdoG26QLrpqrLA== X-Google-Smtp-Source: AAOMgpfR2yRG3aVJUkYAvvMylG5XmI5K05/IB9SUrS4jPfZk+hicoo4G8xhfmX2df+xEVOPCZmfZUg== X-Received: by 2002:a24:9b82:: with SMTP id o124-v6mr6639009itd.56.1532033666369; Thu, 19 Jul 2018 13:54:26 -0700 (PDT) Received: from ?IPv6:::ffff:31.133.157.105? (dhcp-9d69.meeting.ietf.org. [31.133.157.105]) by smtp.gmail.com with ESMTPSA id 80-v6sm247958itl.35.2018.07.19.13.54.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 13:54:25 -0700 (PDT) Message-ID: <5b50fa81.1c69fb81.3575.17b3@mx.google.com> MIME-Version: 1.0 To: Rifaat Shekh-Yusef , oauth From: John Bradley Date: Thu, 19 Jul 2018 16:54:26 -0400 Importance: normal X-Priority: 3 In-Reply-To: References: Content-Type: multipart/alternative; boundary="_CACCADB7-4C54-4AB1-9729-7014CF56B536_" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 20:54:36 -0000 --_CACCADB7-4C54-4AB1-9729-7014CF56B536_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I accept the adoption of this document. Sent from Mail for Windows 10 From: Rifaat Shekh-Yusef Sent: Thursday, July 19, 2018 4:02 PM To: oauth Subject: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.= 0" Hi all, This is the call for adoption of the 'Resource Indicators for OAuth 2.0' do= cument following the positive call for adoption at the Montreal IETF meeting. Here is the document: https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 Please let us know by August 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Regards, Rifaat=20 --_CACCADB7-4C54-4AB1-9729-7014CF56B536_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

 

I accept the adoption of this document.

=  

Sent from Mail for Windows 10

 

 

Hi all,

This = is the call for adoption of the 'Resource Indicators for OAuth 2.0' documen= t
following the positive call for adoption at the Montreal IETF meeting.=

Here is the document:
https://tools.ietf.org/html/draft-ca= mpbell-oauth-resource-indicators-02

Please let us know by August 2nd whether you accept / object to= the
adoption of this document as a starting point for work in the OAuth=
working group.

Regards,
Rifaat

 

= --_CACCADB7-4C54-4AB1-9729-7014CF56B536_-- From nobody Thu Jul 19 14:10:44 2018 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 91DC0130F67 for ; Thu, 19 Jul 2018 14:10:42 -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 NK3yYRnvwVw2 for ; Thu, 19 Jul 2018 14:10:40 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 4B320130F59 for ; Thu, 19 Jul 2018 14:10:40 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id x5-v6so4836897pgp.7 for ; Thu, 19 Jul 2018 14:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vVfmIUU59sKvRd/z0pFs2llqqwS+5eQK4X7qAfiE9kQ=; b=uLF7+fX04TmjZAGrs1nYenErZJajdTlgYXQZIyRKCqRJ3Qd7JS/H1/oiTKHsevDM4w 9tcy/d8ija38d0nbLtDwrkm0Mt2l3sNDqzHxuzIrEoM9BlK5oNOROy2cPXC3izf5AJ37 5q+i4f9gzb87lEEuBwTaQXQ+CqcsdbPinpMP3+jecuL3eNB0IKd/m9SpRZ+H8N9D3OP7 ux/l3AcNvIZb0VF57Zb9dLSAwV/ja+VkvC6AdVmyM81MSBz6avMZP8+/K7CJ3NOBZ0sm woh8qHRpAJ/dxhX4Gan1OAU9PVxihK79YW1EQONNwmrRst464E6bwKrjOzGMgaPwxI+h s7Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vVfmIUU59sKvRd/z0pFs2llqqwS+5eQK4X7qAfiE9kQ=; b=Ldhad37a8Y5NR83m9T3bpBVhE6Ths1ppHdgOOaDMygCuLXjhPWXbXbzm4kOW7C0SiI o4oTS47LWnsO5th/rbg2vyK16jx00FamHYLGYq6cvdgsnwlScaRNUQex9J1UaUOd5pUX pwO211fWz+tTf/M8gEbKkhdUz/ZoI9pwjGE8S0wM60if/4NZ0Cyn9Hk8Lrk3lmZyJ/uH KJb6/Z78ypD3Mqc7AnXnDeIBUZmomh8Kw5AFOPvjKaRlKJO28NUagSOiBzaVlJYQOUla NupnjqmYz/GomG/KL2Vavb56YxITHcmLU4iAWn4s96dTjRTeb/L18j2Ez+o+fKvqBNbE ajOg== X-Gm-Message-State: AOUpUlHVwvF1hEw2jf2pmQq0gHED+m10nHnTIFWFKOzZ07CXAcFeGs6V IKqRch8+Bm50OvH3b9pW4GRz4U8UzzcJYzNpPwQ= X-Google-Smtp-Source: AAOMgpdspqtocmULx/T2IJ/yMxY6sm4tudkyDKFQbRfAUtVBE/HE2l58fdfPelyNnhRJL2gMC5YEvu++8LYNqDyTGjM= X-Received: by 2002:a62:f50b:: with SMTP id n11-v6mr11083312pfh.120.1532034639742; Thu, 19 Jul 2018 14:10:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Thu, 19 Jul 2018 14:10:19 -0700 (PDT) In-Reply-To: <5b50fa81.1c69fb81.3575.17b3@mx.google.com> References: <5b50fa81.1c69fb81.3575.17b3@mx.google.com> From: Dick Hardt Date: Thu, 19 Jul 2018 17:10:19 -0400 Message-ID: To: John Bradley Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="0000000000007c4d3f0571609ce1" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 21:10:43 -0000 --0000000000007c4d3f0571609ce1 Content-Type: text/plain; charset="UTF-8" I support adoption of this document. On Thu, Jul 19, 2018 at 4:54 PM, John Bradley wrote: > > > I accept the adoption of this document. > > > > Sent from Mail for > Windows 10 > > > > *From: *Rifaat Shekh-Yusef > *Sent: *Thursday, July 19, 2018 4:02 PM > *To: *oauth > *Subject: *[OAUTH-WG] Call for adoption for "Resource Indicators for > OAuth 2.0" > > > > Hi all, > > This is the call for adoption of the 'Resource Indicators for OAuth 2.0' > document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Regards, > Rifaat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0000000000007c4d3f0571609ce1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of this document.

On Thu, Jul 19, 2018 at 4:54 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:

=C2= =A0

I accept the adoption of this document= .

=C2=A0

= Sent from Mail for Windows 10

=C2= =A0

From: Rifaat Shekh-Yusef
Sent: Thursday, July 19= , 2018 4:02 PM
To: oauth
Subject: [OAUTH-WG] Call for adoption for = "Resource Indicators for OAuth 2.0"

=C2=A0

Hi all,

This is the call for adoption= of the 'Resource Indicators for OAuth 2.0' document
following t= he positive call for adoption at the Montreal IETF meeting.

Here is = the document:
https://tools.ietf.org/html/draft-campbell-oaut= h-resource-indicators-02
Please let us know by August 2nd whether you accept / object to theadoption of this document as a starting point for work in the OAuth
wo= rking group.

Regards,
Rifaat

=C2=A0


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


--0000000000007c4d3f0571609ce1-- From nobody Thu Jul 19 14:11:42 2018 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 CEFA5130F7B for ; Thu, 19 Jul 2018 14:11: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, 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 3WEB9W7UJIIh for ; Thu, 19 Jul 2018 14:11:37 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 76443130F59 for ; Thu, 19 Jul 2018 14:11:37 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id r5-v6so4849657pgv.0 for ; Thu, 19 Jul 2018 14:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iXpX0s4T9gJsVZH6rozIfpurE4rk1+BoSO2UW+e9bKc=; b=bVhk71MUvmxV5uMdUBqk6yvVklEgmTB5ewiridpjmdWUvgU5br2Ms1aTBxIxCG+62l LtW059lJFzeSh8n6PtpcF6ZZpLtg8VelTN8WyHeGK5J56GP9Y6gLQezvTsw5jrDMiwct KJGWWSHyrCdZdUudjT1QZl8WR735sSfeocTN4ZDDcCqucrb7J8oNiUbrwkTgRHBVp5EE KWvuLa9PJw6dVw5dGh46i1LFt9KPR8Li9Ju0fwOocu69AkYFV/mpK0RO7ckK/qCFR6Q1 x/nC2OBOQImi0134xwRPCJQH8t9GIwBFbX8fJagowHhnIKnh6xh837yLLUvt5bxcTCGL 1kVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iXpX0s4T9gJsVZH6rozIfpurE4rk1+BoSO2UW+e9bKc=; b=puZ0M/2L6FeViTf55gzw8kMDajkUKcqHFHV7WqLN/gTPxi4VFztMvuSztZ/AHyzwV8 LMFGNi0fg70hOrsMhudBXFFPctUzuUJVoxStTnc7O0iGlDzVL9zzQblnbqQHVgV1J98o 49dEbFkJ9e4SOxrXfQ5DTB7gvkuxDVk9TRCAm8UKdiPYLhfe7ClAAKyeuELKXQDzbSYS GRM1BdgYFMsX2wdhSgR+3nVnpbK8Tunn5k8JiuornpVXj7AIFlvxN6qxnxHki701nNi4 nIYQ8wTU+fsjOAgTiPOX38R3yFSc2Q6+moZ1YRcHkUWRdtz2ZZGERXl92kXZGWfdM0wJ p0Gg== X-Gm-Message-State: AOUpUlEJxnrd1wN/LQ0US9CdDuoazUO2yaCRJt2s4wQNgLsxW6z64DhI 222taB5i92ywYzTYxLElBp0hGLK0h6/1CWEg1Gc= X-Google-Smtp-Source: AAOMgpfxnAjDMkAOBYy81W4x22iqixRLqs2iKV4VrZ0CAGJNcnEdFLWi6yU1Y4eyjpbWkL7tdPd02pkFdPHOd56G+NU= X-Received: by 2002:a63:6243:: with SMTP id w64-v6mr11471748pgb.179.1532034696930; Thu, 19 Jul 2018 14:11:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Thu, 19 Jul 2018 14:11:16 -0700 (PDT) In-Reply-To: References: From: Dick Hardt Date: Thu, 19 Jul 2018 17:11:16 -0400 Message-ID: To: Mike Jones Cc: William Denniss , Hannes Tschofenig , oauth Content-Type: multipart/alternative; boundary="000000000000e4eb480571609f19" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 21:11:41 -0000 --000000000000e4eb480571609f19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable William: there was discussion in the meeting about the PoP document using "resource" rather than "aud" On Thu, Jul 19, 2018 at 4:53 PM, Mike Jones < Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > Microsoft=E2=80=99s Azure AD OAuth server has used the resource=3D parame= ter since > at least 2012 to indicate what resource the requested access token is to = be > for. > > > > -- Mike > > > > *From:* William Denniss > *Sent:* Thursday, July 19, 2018 4:40 PM > *To:* Hannes Tschofenig > *Cc:* Mike Jones ; oauth > *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for > OAuth 2.0" > > > > Thanks! I assume then that there are use-cases for this that are outside > the Distributed OAuth use-case? Did we document them? I'm supportive (of > both drafts), but think we should get the rationale on the record since t= he > option to incorporate this spec in Distributed OAuth was raised in the > meeting. > > > > > > On Thu, Jul 19, 2018 at 1:34 PM, Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi William, > > > > that was the idea. > > > > Ciao > > Hannes > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William > Denniss > *Sent:* 19 July 2018 16:32 > *To:* Mike Jones > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for > OAuth 2.0" > > > > Question: if this is adopted along with https://datatracker.ietf. > org/doc/draft-hardt-oauth-distributed/, is the plan for this spec to be > the authoritative definition, and Distributed OAuth to take a reference > instead of redefining? > > > > On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones com@dmarc.ietf.org> wrote: > > I support adoption. The =E2=80=9Cresource=E2=80=9D request parameter tha= t it defines is > already widely used. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of *Rifaat Shekh-Yusef > *Sent:* Thursday, July 19, 2018 4:02 PM > *To:* oauth > *Subject:* [OAUTH-WG] Call for adoption for "Resource Indicators for > OAuth 2.0" > > > > Hi all, > > This is the call for adoption of the 'Resource Indicators for OAuth 2.0' > document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Regards, > Rifaat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > 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 > > --000000000000e4eb480571609f19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
William: there was discussion in the meeting about the PoP= document using "resource" rather than "aud"

On Thu, Jul 19, 2018 a= t 4:53 PM, Mike Jones <Michael.Jones=3D40micr= osoft.com@dmarc.ietf.org> wrote:

Microsoft=E2=80=99s Az= ure AD OAuth server has used the resource=3D parameter since at least 2012 = to indicate what resource the requested access token is to be for.

=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=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=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 -- Mike

=C2=A0

From: William Denniss <wdenniss@google.com>
Sent: Thursday, July 19, 2018 4:40 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicat= ors for OAuth 2.0"

=C2=A0

Thanks! I assume then that there are use-cases for t= his that are outside the Distributed OAuth use-case? Did we document them?= =C2=A0 I'm supportive (of both drafts), but think we should get the rat= ionale on the record since the option to incorporate this spec in Distributed OAuth was raised in the meeting.

=C2=A0

=C2=A0

On Thu, Jul 19, 2018 at 1:34 PM, Hannes Tschofenig &= lt;Hannes.Ts= chofenig@arm.com> wrote:

Hi Will= iam,

=C2=A0<= /span>

that wa= s the idea.

=C2=A0

Ciao

Hannes<= /span>

=C2=A0<= /span>

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of William Denniss
Sent: 19 July 2018 16:32
To: Mike Jones
Cc: oauth
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicat= ors for OAuth 2.0"

=C2=A0

Question: if this is adopted al= ong with=C2=A0https://datatracker.ietf.org/doc/draft-hardt-oauth-distribute= d/, is the plan for this spec to be the authoritative definition, and Distribu= ted OAuth to take a reference instead of redefining?

=C2=A0

On Thu, Jul 19, 2018 at 1:29 PM= , Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.o= rg> wrote:

I support adoption.=C2= =A0 The =E2=80=9Cresource=E2=80=9D request parameter that it defines is alr= eady widely used.

=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=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=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 -- Mike

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 4:02 PM
To: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] Call for adoption for "Resource Indicators = for OAuth 2.0"

=C2=A0

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://too= ls.ietf.org/html/draft-campbell-oauth-resource-indicators-02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat

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

=C2=A0

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other perso= n, use it for any purpose, or store or copy the information in any medium. = Thank you.

=C2=A0


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


--000000000000e4eb480571609f19-- From nobody Thu Jul 19 14:12:04 2018 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 E46231310A7 for ; Thu, 19 Jul 2018 14:12: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, 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 mB2B3LcxQuvY for ; Thu, 19 Jul 2018 14:11:58 -0700 (PDT) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (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 8ECFE130FED for ; Thu, 19 Jul 2018 14:11:58 -0700 (PDT) Received: by mail-pl0-x236.google.com with SMTP id p23-v6so4181928plo.6 for ; Thu, 19 Jul 2018 14:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pcwi6WLd08+sURBUxhwVDD/ogRiNgdfXdi64yqUR7l4=; b=fzlsnPJVPSiqbKVe3d3QTLdXY6QXBsPRQil/Moc9Y1o5VuIhAzyeeqJyzzI/5OHP9q 1Qhb9I4+vNhGELM2cKsCmshxYH3WrrIIQloDveBZDhWp6jmNn7Qqyd8qVYLU1e+5OAaz /RhqUnoSNmArAVDGokM30gkheobdGLHzJ+JNv4bKH2CSTBtoYw8MQOoN+gtSTS3+UhXt 9cqCXIDKofuglKqfkIVQio1P9W5OREjFIkt0oCaeZqDfbRcpVgwRI1/NMBaEYlnO8kUC Q3rHm13kD5vuijjX7vErflJCGPql8LULHFPMlSe5AUXbbrn4GuM5Ix6cfjVmVNRBVNzu m+iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pcwi6WLd08+sURBUxhwVDD/ogRiNgdfXdi64yqUR7l4=; b=RJBRe087xvda7quFsp6nG/8l9tw5F7fnM05irXXFG5akqKRUvE0es/s8ykx2pzqI69 DaGwJJ8X0TQJdGRipe37g/rs+IF4kaFv015Ki+EM+SX0U5/l5zYPVhe8GigYqSfm70HQ NSeU/foc9qaf7wQv6cjPe9RYEOWDV0uWJMvUXmlcFL3lWRtynilBoazKovOEbkEZC2ZT I9EmrHLSP2iPJpSO9o2YcTT1OiBrTrwulKPs86zLyxzYzizEeFXfpBAj5fwjL6EXaymT GXVxTmnKhKXuhko7T6uCqkYMepfxFU74CD15j0gGcHZNwAws/C9gRt33SyKAaPzG7rXN U0EA== X-Gm-Message-State: AOUpUlGh0A/73Ugw/dT8/mm4PCZ1jsshplzVmQG8sAU9xx9BrYUwpMzn 47g92uWoxl7Xe1suKWq3IMMP+m+dXuEWV0P7ThE= X-Google-Smtp-Source: AAOMgpeq3op1QAM53P35FaPtHnUA7nh2NiRSEtYQ6sIqbM8PhZsK/HF3ItLNEe4csfUBKic1vqJVktFCKwVVMVSXcvY= X-Received: by 2002:a17:902:8c84:: with SMTP id t4-v6mr11811571plo.100.1532034718085; Thu, 19 Jul 2018 14:11:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Thu, 19 Jul 2018 14:11:37 -0700 (PDT) In-Reply-To: References: From: Dick Hardt Date: Thu, 19 Jul 2018 17:11:37 -0400 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="00000000000027b757057160a104" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 21:12:03 -0000 --00000000000027b757057160a104 Content-Type: text/plain; charset="UTF-8" I'm supportive. :) On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef wrote: > Hi all, > > This is the call for adoption of the 'Distributed OAuth' document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ > > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Regards, > Hannes & Rifaat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00000000000027b757057160a104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm supportive. :)
On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Y= usef <rifaat.ietf@gmail.com> wrote:
Hi all,

This = is the call for adoption of the 'Distributed OAuth' document
<= div>following the positive call for adoption at the Montreal IETF meeting.<= /div>

Here is the document:




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


--00000000000027b757057160a104-- From nobody Thu Jul 19 15:36:44 2018 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 D8A3C130ED1 for ; Thu, 19 Jul 2018 15:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 zmxh4cKWCQ8g for ; Thu, 19 Jul 2018 15:36:38 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 7024B130E5B for ; Thu, 19 Jul 2018 15:36:38 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id b77-v6so5190668vkb.5 for ; Thu, 19 Jul 2018 15:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eHJWVFb2XeBmpdkBYNR4kwQQL6cI6tNjhIH3ozFhCX0=; b=swo/SnZe4mQ+Ikr05FHAeBjUlCkREsivbdKgFUzrKku8TKGqy4oDrM9cInsr0mll7G Sxnf8LK9c25LLcgQQ4FPD0wJZijocbYvxQIo1CUv923Wyh4OuRk6L5qt5nGYbzX5o5O5 4xqvqccY8rC9T6a29pbOWo7doa2SpE/CUnaWLdaRfqpkZmukY5oAgRrgmsqjBheWK4rI eHG33YgAwAVU1P+vRtclEHXV2Q1kv3AxJ265r8mJWVlPM3CA4gNoC2byRspoV/saAujQ xzpeyCdmqLlRvkI+JBnN0IEf6O9vV7Hk1JDmsL+qTr6EZLNq+QoTUoiPbceeZnlL4omC zjbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eHJWVFb2XeBmpdkBYNR4kwQQL6cI6tNjhIH3ozFhCX0=; b=BhBspXC1XOkl8lmjeEHqHWVmywaBmInOrTDN1vC1sMhonrnXWbex5Wly3QJtv9gj6S RH2tCW5OyZcyrYJ7n8V/vi9rp/yM+PBwHQDUX6o9iOfmoqt3KurT8SCWTJSAO22aWfLn WjzStMWMaiMezPf4m/hXNFM40V6+iUNuSKFi9ZLRoz2fCyMJAGYMTreqbjbzTqko3yUL aMejWsazHTx6hXqQOCVnt9IVZ+jrJX2tq90YKnBawpyaySPKX3iqFUl68h/EeORaz5aw PyUcwXifg++WjfJqJKqf0iE3xZ/N6xvEUOQeWioirG4JF7MI6+5cXMeS2Somz87TNB41 /5Dg== X-Gm-Message-State: AOUpUlGgKjj+K0qgQTQpt1OVSuW63IrlD17msTmCtiB7cxnK40FB4iga BUd/RDYQDieBXn97o2zKg6kd6uPw9t+IoLiTyLu5QQ== X-Google-Smtp-Source: AAOMgpczDG1/03XZJfjTnaFn5aMn0Baqaqe25gXLcbseGUOHy84vJYXp+EzQVu/VwEeK3NbqaDjreVXuW3X4lFJCLNY= X-Received: by 2002:a1f:6285:: with SMTP id w127-v6mr7484097vkb.78.1532039797038; Thu, 19 Jul 2018 15:36:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:6383:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 15:36:16 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Thu, 19 Jul 2018 15:36:16 -0700 Message-ID: To: Dick Hardt Cc: Mike Jones , Hannes Tschofenig , oauth Content-Type: multipart/alternative; boundary="000000000000e2f651057161cfd3" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:36:42 -0000 --000000000000e2f651057161cfd3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes there was. +1 to adopt this document. On Thu, Jul 19, 2018 at 2:11 PM, Dick Hardt wrote: > William: there was discussion in the meeting about the PoP document using > "resource" rather than "aud" > > On Thu, Jul 19, 2018 at 4:53 PM, Mike Jones com@dmarc.ietf.org> wrote: > >> Microsoft=E2=80=99s Azure AD OAuth server has used the resource=3D param= eter since >> at least 2012 to indicate what resource the requested access token is to= be >> for. >> >> >> >> -- Mike >> >> >> >> *From:* William Denniss >> *Sent:* Thursday, July 19, 2018 4:40 PM >> *To:* Hannes Tschofenig >> *Cc:* Mike Jones ; oauth >> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for >> OAuth 2.0" >> >> >> >> Thanks! I assume then that there are use-cases for this that are outside >> the Distributed OAuth use-case? Did we document them? I'm supportive (o= f >> both drafts), but think we should get the rationale on the record since = the >> option to incorporate this spec in Distributed OAuth was raised in the >> meeting. >> >> >> >> >> >> On Thu, Jul 19, 2018 at 1:34 PM, Hannes Tschofenig < >> Hannes.Tschofenig@arm.com> wrote: >> >> Hi William, >> >> >> >> that was the idea. >> >> >> >> Ciao >> >> Hannes >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William >> Denniss >> *Sent:* 19 July 2018 16:32 >> *To:* Mike Jones >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for >> OAuth 2.0" >> >> >> >> Question: if this is adopted along with https://datatracker.ietf. >> org/doc/draft-hardt-oauth-distributed/, is the plan for this spec to be >> the authoritative definition, and Distributed OAuth to take a reference >> instead of redefining? >> >> >> >> On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones < >> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> I support adoption. The =E2=80=9Cresource=E2=80=9D request parameter th= at it defines is >> already widely used. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *Rifaat Shekh-Yusef >> *Sent:* Thursday, July 19, 2018 4:02 PM >> *To:* oauth >> *Subject:* [OAUTH-WG] Call for adoption for "Resource Indicators for >> OAuth 2.0" >> >> >> >> Hi all, >> >> This is the call for adoption of the 'Resource Indicators for OAuth 2.0' >> document >> following the positive call for adoption at the Montreal IETF meeting. >> >> Here is the document: >> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 >> >> Please let us know by August 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >> >> Regards, >> Rifaat >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> 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 t= he >> information in any medium. Thank you. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --000000000000e2f651057161cfd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes there was.

+1 to adopt this document.


On Thu, Jul 19, 2018 at 2:11 PM, Dic= k Hardt <dick.hardt@gmail.com> wrote:
William: there was discussion in the meetin= g about the PoP document using "resource" rather than "aud&q= uot;

On Thu, Jul 19, 2018 at 4:53 PM, Mike Jone= s <Michael.Jones=3D40microsoft.com@dmarc= .ietf.org> wrote:

Microsoft=E2=80=99s Az= ure AD OAuth server has used the resource=3D parameter since at least 2012 = to indicate what resource the requested access token is to be for.

=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=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=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 -- Mike

=C2=A0

From: William Denniss <wdenniss@google.com>
Sent: Thursday, July 19, 2018 4:40 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicat= ors for OAuth 2.0"

=C2=A0

Thanks! I assume then that there are use-cases for t= his that are outside the Distributed OAuth use-case? Did we document them?= =C2=A0 I'm supportive (of both drafts), but think we should get the rat= ionale on the record since the option to incorporate this spec in Distributed OAuth was raised in the meeting.

=C2=A0

=C2=A0

On Thu, Jul 19, 2018 at 1:34 PM, Hannes Tschofenig &= lt;Hannes.Ts= chofenig@arm.com> wrote:

Hi Will= iam,

=C2=A0<= /span>

that wa= s the idea.

=C2=A0

Ciao

Hannes<= /span>

=C2=A0<= /span>

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of William Denniss
Sent: 19 July 2018 16:32
To: Mike Jones
Cc: oauth
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicat= ors for OAuth 2.0"

=C2=A0

Question: if this is adopted al= ong with=C2=A0https://datatracker.ietf.org/doc/draft-hardt-oauth-distribute= d/, is the plan for this spec to be the authoritative definition, and Distribu= ted OAuth to take a reference instead of redefining?

=C2=A0

On Thu, Jul 19, 2018 at 1:29 PM= , Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.o= rg> wrote:

I support adoption.=C2= =A0 The =E2=80=9Cresource=E2=80=9D request parameter that it defines is alr= eady widely used.

=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=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=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 -- Mike

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 4:02 PM
To: oauth <oa= uth@ietf.org>
Subject: [OAUTH-WG] Call for adoption for "Resource Indicators = for OAuth 2.0"

=C2=A0

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://too= ls.ietf.org/html/draft-campbell-oauth-resource-indicators-02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat

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

=C2=A0

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other perso= n, use it for any purpose, or store or copy the information in any medium. = Thank you.

=C2=A0


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



--000000000000e2f651057161cfd3-- From nobody Thu Jul 19 15:42:58 2018 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 555AE130FA8 for ; Thu, 19 Jul 2018 15:42:51 -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=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 1HiCFPyCejWq for ; Thu, 19 Jul 2018 15:42:46 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 1595A130FFE for ; Thu, 19 Jul 2018 15:42:44 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 16-v6so12133668itl.5 for ; Thu, 19 Jul 2018 15:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DZVTMY8bjk0avcc1zp0jp5QFoNRn/O2ChVrXoHejISY=; b=ClcxDBDTKjl0ixGeeMmM4vLn5ilwaoHGMAtd+sY06smAupkx+1M+ZLQdK1peF2YzRG nYp5FT7hlvp9ohmN0l/PknT0X8CRZ/SkoNMgjrJibDWmKVPqtvN8+OsVzIxPfYOpf1Bo ECJYvj4G2w4kFLJbzaBFQKrYg0LI3NVqDFXzE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DZVTMY8bjk0avcc1zp0jp5QFoNRn/O2ChVrXoHejISY=; b=lpcRj8iTAnRKOWa8aM30YG9mtvXzqpTEzsv1oQupYiCKX/gHmYDpBYO2rn59xgq8zc pvutXxCoD80JKrKK4canzR0nONSv3z/vE8scfLD8Ed7tsop1gitnmx+HHNfthBJHSqIN d+ZqrnO5sa9M7IX2rcJgZNNoT8T7AQa1v+iyiWWZ4t0A+KK4ILQZ2gIIr1bdFkyt8Spo tmJ87KoMzgK3miUKqMKQhedAYOd9JEOacZHuKcMVcFRwGlRfj3wdGsED4aN1wa+SQkSq jmrkgGaGMJ39LDJronX3k9m4G8RuCjByxngw957McmZfkK4y1u64t8ftKXV+JqEfiIW7 s8kQ== X-Gm-Message-State: AOUpUlHD2yWyKamnSBpRRQn13N//dCeeWzMW+j/TSsm3neDkryb9KK8c x1H4D2s0WWdrSPRGhkZiXT1u5WiYcgsJ8DfYopuSkMx9tczaeHm3ziwE59szGGIkkoiA3vJwUQM 62/Xr/dVMlHrOmw== X-Google-Smtp-Source: AAOMgpddJrJC2V9Kknuf77fvUwer0VSoNgICXrVlN/5Ks4fYcRQiq0IKhH51MXbZDNZ+rn59Bpi7Vw3hBHqxJKbFAbc= X-Received: by 2002:a24:19d5:: with SMTP id b204-v6mr7054420itb.25.1532040163276; Thu, 19 Jul 2018 15:42:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6d18:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 15:42:12 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 19 Jul 2018 18:42:12 -0400 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="000000000000b6d4cb057161e58e" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:42:57 -0000 --000000000000b6d4cb057161e58e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption of this document. On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef wrote: > Hi all, > > This is the call for adoption of the 'Resource Indicators for OAuth 2.0' > document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Regards, > Rifaat > > _______________________________________________ > 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._ --000000000000b6d4cb057161e58e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of this document.

On Thu, Jul 19, 2018 at 4:0= 1 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:<= br>
Hi all,
This is the call for= adoption of the 'Resource Indicators for OAuth 2.0' document
following the po= sitive call for adoption at the Montreal IETF meeting.

Here is the docu= ment:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

Please let us know by = August 2nd whether you accept / object to the
adoption of this document as a starting = point for work in the OAuth
working group.

Regards,
Rifaat

_______________________________________________
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. --000000000000b6d4cb057161e58e-- From nobody Thu Jul 19 16:55:59 2018 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 6F303130E43 for ; Thu, 19 Jul 2018 16:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 Epq0Na-KnOQL for ; Thu, 19 Jul 2018 16:55:54 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0612.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::612]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C89D130E6D for ; Thu, 19 Jul 2018 16:55:49 -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=hqZ8y2jpucqIYWWm2A37yFmWzHCxPOcD8/5VvnDgXko=; b=Kv7d5pNpKX5RFW+/516XOJYjOF0aUbzWNjIKoOaYqjXjuvEaTJkCvsnrxFsjrCa4x0aqBQXt90sdVqNIMC05P8XMnla0fx/zuQVxfsUvq4t/hNLFP91CkWKBT8Ba5oDbIlrnr/qxJ5CUYlbD5NABRnX+IYphZDuaOR2jeVbK0vk= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1325.eurprd08.prod.outlook.com (10.167.197.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.21; Thu, 19 Jul 2018 23:55:43 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Thu, 19 Jul 2018 23:55:43 +0000 From: Hannes Tschofenig To: Rifaat Shekh-Yusef , oauth Thread-Topic: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" Thread-Index: AQHUH5tpWfx6ee5zikCyGLNHikwcWqSXN4Ng Date: Thu, 19 Jul 2018 23:55:43 +0000 Message-ID: References: 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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1325; 6:DdFrsPHlfedB3HNZC7nnDWa8yw37GL303p/AxH7NP9Y9VxZnnn7caroGjSPVcX1Zbw2YtYVXWw5G2f4yAfcky+4tp/6WyDHY/gPZHI7ztfTwn73Y3zCR6r0aaRtwztSpzZQza8EGZDgk/mGQ+FQSsbWu462zcA46CEnT0veXP6I6E0L8xKzWB+Mddclol2FJdjP9WOfiZDDifWg4y7Ds5HUmA89uk6T2ogsAuLmarATac8r2nXvktmeOM8f3t1zNaAtzP5y2DfGTLOco8FwP9eQKT5faUwp04VWp4zF+b//pzFXUn2dF/OqTdDr0RgerwW/DDXSaqh9ETSi3sh15/8uae45A7EccAo0QJHRdc5GccCcDLDRpYztpA4Ksi1OTz2m/39d8vt1oigjdhBEYt5aZaKWusoaiJd/KemV/aj4WZXwutbYsEyEF3Ki4CRUJBNCvqNDJMin3Ee8O7vemjw==; 5:twJJ70sn8yy0xJQZtiQYAXGu+3jPiSkOpn3lMeL90FHpS4xq6k/miWItSEJ4X24aAveTCst2Jo8kjaPNb66ewd+XiL+9V39EK1RJP1brs5yE9jJVPhQZkTAZhDZpBIXghh5FHXotklD79qPQtFOZp2xyO3p5wxcN4jWC437C5dc=; 7:amDhi4x2q0ik6SGBn9QmUld3+P9oR77TF/duwei5lBHusm3XbrO4Y66I5NhSDMuDqKbJhkQgBDk7WRJY/WX8BWdagC4rCwz2IfZfVwGe8n/ip7fFwCAvMWY+zO3vJJIOpY1uQNeqkCPlb9FPoSTgEBN51WTod/NbIZ0XZTGzEjXZVpn3ZMZTdx6ZT8yY+VZWqfZd6Qi3VDJjB5ZV+z6uB7dmt5tBcgoxPKg1TybH/S+mK2coAC7SbNSs0ZGg5IKj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 898d6372-c27d-4a41-9d86-08d5edd323a5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1325; x-ms-traffictypediagnostic: VI1PR0801MB1325: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1325; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1325; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(39860400002)(376002)(346002)(396003)(189003)(199004)(40434004)(53754006)(229853002)(5660300001)(478600001)(99286004)(33656002)(9686003)(6306002)(54896002)(236005)(55016002)(2906002)(476003)(2900100001)(486006)(6436002)(11346002)(446003)(606006)(110136005)(72206003)(966005)(6116002)(790700001)(106356001)(3846002)(14454004)(105586002)(316002)(7736002)(53936002)(39060400002)(6246003)(76176011)(7696005)(256004)(102836004)(26005)(53546011)(6506007)(14444005)(97736004)(74316002)(186003)(5250100002)(5024004)(66066001)(81166006)(81156014)(8936002)(8676002)(86362001)(25786009)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1325; 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-microsoft-antispam-message-info: 5R2eUQIhYjqe7ge710nM2oU0haz9XgMXs6GoaaA/MFOZ+E3bJ3sgLJYOqdPJoU9ZuNvagibi6hhuBaYJH2uZwLRdiYuCsWAzRTwjEzEESE8V3iMby7RxBFGvkGbTM20y6hLEP8YOmy75Ri1ZBs/QBunr43Ph7DYfOLOfZOtXvry2U8oajJYQqLheio57JUcBP+NqFm6gBeoSXR4X10ANoLDVOxX84VQNl8uDVz/eTFAY+c5EvPVyIfTQRKliPxCPzUZnA0OEGAIjiv80t7PtQ+PI8TJR8tycemJOrEmWbkwCKYR3L6YX8j90NwigbrrZHtZAQ4LBOAD88OHnSugAIGKVZMwPMDt2J3rWIzAXqiI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112EDC2FFEAEDEC180E7A24FA520VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 898d6372-c27d-4a41-9d86-08d5edd323a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 23:55:43.3781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1325 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:55:58 -0000 --_000_VI1PR0801MB2112EDC2FFEAEDEC180E7A24FA520VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIHN1cHBvcnQgdGhlIGFkb3B0aW9uLiBJIGhhZCBiZWVuIHB1c2hpbmcgZm9yIHRoaXMg d29yayBpbiBPQXV0aCBmb3IgYSBsb25nIHRpbWUgYW5kIG5vdyB3ZSBhbHNvIG5lZWQgaXQgZm9y IHRoZSB3b3JrIGluIEFDRSBhcyB3ZWxsLg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSaWZhYXQgU2hla2gtWXVzZWYNClNlbnQ6IDE5 IEp1bHkgMjAxOCAxNjowMg0KVG86IG9hdXRoDQpTdWJqZWN0OiBbT0FVVEgtV0ddIENhbGwgZm9y IGFkb3B0aW9uIGZvciAiUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4wIg0KDQpIaSBh bGwsDQoNClRoaXMgaXMgdGhlIGNhbGwgZm9yIGFkb3B0aW9uIG9mIHRoZSAnUmVzb3VyY2UgSW5k aWNhdG9ycyBmb3IgT0F1dGggMi4wJyBkb2N1bWVudA0KZm9sbG93aW5nIHRoZSBwb3NpdGl2ZSBj YWxsIGZvciBhZG9wdGlvbiBhdCB0aGUgTW9udHJlYWwgSUVURiBtZWV0aW5nLg0KDQpIZXJlIGlz IHRoZSBkb2N1bWVudDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVs bC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAyDQoNClBsZWFzZSBsZXQgdXMga25vdyBieSBB dWd1c3QgMm5kIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGUNCmFkb3B0aW9uIG9m IHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBpbiB0aGUgT0F1dGgN CndvcmtpbmcgZ3JvdXAuDQoNClJlZ2FyZHMsDQpSaWZhYXQNCklNUE9SVEFOVCBOT1RJQ0U6IFRo ZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk byBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBm b3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_VI1PR0801MB2112EDC2FFEAEDEC180E7A24FA520VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWxzbyBzdXBwb3J0IHRoZSBhZG9wdGlvbi4gSSBoYWQg YmVlbiBwdXNoaW5nIGZvciB0aGlzIHdvcmsgaW4gT0F1dGggZm9yIGEgbG9uZyB0aW1lIGFuZCBu b3cgd2UgYWxzbyBuZWVkIGl0IGZvciB0aGUgd29yayBpbiBBQ0UgYXMgd2VsbC4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29t cG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJpZmFhdCBTaGVraC1ZdXNlZjxi cj4NCjxiPlNlbnQ6PC9iPiAxOSBKdWx5IDIwMTggMTY6MDI8YnI+DQo8Yj5Ubzo8L2I+IG9hdXRo PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb24gZm9yICZx dW90O1Jlc291cmNlIEluZGljYXRvcnMgZm9yIE9BdXRoIDIuMCZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCw8YnI+DQo8YnI+DQpUaGlzIGlzIHRoZSBj YWxsIGZvciBhZG9wdGlvbiBvZiB0aGUgJ1Jlc291cmNlIEluZGljYXRvcnMgZm9yIE9BdXRoIDIu MCcgZG9jdW1lbnQ8YnI+DQpmb2xsb3dpbmcgdGhlIHBvc2l0aXZlIGNhbGwgZm9yIGFkb3B0aW9u IGF0IHRoZSBNb250cmVhbCBJRVRGIG1lZXRpbmcuPGJyPg0KPGJyPg0KSGVyZSBpcyB0aGUgZG9j dW1lbnQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNh bXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDIiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6IzExNTVDQyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWNhbXBiZWxsLW9hdXRoLXJlc291cmNlLWluZGljYXRvcnMtMDI8L3NwYW4+PC9hPjxicj4NCjxi cj4NClBsZWFzZSBsZXQgdXMga25vdyBieSBBdWd1c3QgMm5kIHdoZXRoZXIgeW91IGFjY2VwdCAv IG9iamVjdCB0byB0aGU8YnI+DQphZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGFzIGEgc3RhcnRp bmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhlIE9BdXRoPGJyPg0Kd29ya2luZyBncm91cC48YnI+DQo8 YnI+DQpSZWdhcmRzLDxicj4NClJpZmFhdCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkg dGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_VI1PR0801MB2112EDC2FFEAEDEC180E7A24FA520VI1PR0801MB2112_-- From nobody Thu Jul 19 23:20:17 2018 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 C33EC130E74 for ; Thu, 19 Jul 2018 23:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.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 nac0gnsjsaua for ; Thu, 19 Jul 2018 23:20:11 -0700 (PDT) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBF8130EA7 for ; Thu, 19 Jul 2018 23:20:08 -0700 (PDT) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs02.index.or.jp (Postfix) with ESMTP id 6EF1A196874; Fri, 20 Jul 2018 15:20:07 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id EF26A4E0046; Fri, 20 Jul 2018 15:20:06 +0900 (JST) Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id w6K6K6MZ030874; Fri, 20 Jul 2018 15:20:06 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp with ESMTP id w6K6K6vB030870; Fri, 20 Jul 2018 15:20:06 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w6K6K6XV023941; Fri, 20 Jul 2018 15:20:06 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id w6K6K63V023939; Fri, 20 Jul 2018 15:20:06 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w6K6K67C023935; Fri, 20 Jul 2018 15:20:06 +0900 Received: from CUEXE01PA.cu.nri.co.jp (192.51.23.31) by CUEXM03PA.cu.nri.co.jp (172.159.253.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 20 Jul 2018 15:20:05 +0900 Received: from APC01-HK2-obe.outbound.protection.outlook.com (65.55.88.216) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 20 Jul 2018 15:20:05 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dTELYUUz0vbOIwOQGpu8qieUNzyjqc4bypEOAX9gwqk=; b=Rv3PM8zT2oI29JX1XSNI+XNMjP5qzP0ROJPfoyqlBZCdjbqCMdCnoG4RXoN6oS53JCzS5HPWV+5ec7WCd+D1q2vkXuQmWDL7XEtYL4wOv6Ppo6sG2lrrx05KnxfXhGLD7sV/hLskN9gz/zXLXR17e8oEe6NxJH2tVy9E5aGqS1M= Received: from TY2PR01MB2297.jpnprd01.prod.outlook.com (52.133.184.14) by TY2PR01MB1897.jpnprd01.prod.outlook.com (52.133.181.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Fri, 20 Jul 2018 06:20:03 +0000 Received: from TY2PR01MB2297.jpnprd01.prod.outlook.com ([fe80::a80c:6cfe:7925:86f4]) by TY2PR01MB2297.jpnprd01.prod.outlook.com ([fe80::a80c:6cfe:7925:86f4%2]) with mapi id 15.20.0952.022; Fri, 20 Jul 2018 06:20:03 +0000 From: n-sakimura To: Brian Campbell , "Rifaat Shekh-Yusef" CC: oauth Thread-Topic: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" Thread-Index: AQHUH5tuYAqf5o+kk0m6ex6lcWR7cKSXJEAAgAB/06A= Date: Fri, 20 Jul 2018 06:20:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: 20170719 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [133.250.250.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY2PR01MB1897; 6:/BopZhQAj1/KWI1CHDpuzsHhSmlgCmR4Kd9jgCJNL0+mcqdTyHCedShIGNrjePcrxvB9cDD3Pkb8cn+DQGNNxFLh7Ho6n7TiMJh41Koo4pZ8eUTQ4zPYYqDqf7BbI81dEDMvdM/c7Hgi0fAQGMVA0eOLSMgnoafkK8Xke+RZmkbCFkNLZ+JLELpIxuS/ZSt2duihVqcSVnLwN3uquBYv6T3rijzJBpdo9mmMRmaDnu0n87iqy4UQpF/DQ0Nj9B0JLNChSto05W8+zSFb2bOmCCOi+zZBvwIfZMhm79loNkoVUd7GVcMTlYKkcqqvEd/SeiAFbjxYQZ8wv8porDsPQAZ0Ij2paWiJOqAdL7XUisQQgWTr+LiEg4xPiK1/CtaGLMwjXVQogDN1jPXB0liAeXeFkOQDnuFej6B8fGRy4fLlJDB7LHD4J1WO+MDvk3if96aoamnJuV9RYlmEbwUgoQ==; 5:A6W9rVA0hxDRzYUNNcN+CmdfZJH/H3c/O87uDXsaG1cDz/ZoXg9FKg8xO34pX7+El1R0uYFQ528HSKjh6UyX8R8ECU7DV7vjefovfK5CirDxUPLNSVXdYY8gZD3um2klln57TzGxpnmgLDaLjzGirp7ya/fe63bQKZMM7rfOtlw=; 7:szV8oTZntokX+zSbvuzTL2vnyTU/d3nw8euSgBDh3qkkJxTeg9KZ/Kq3FG2gVbXDIoesxgrsbUqFZ4q52EBmVwXtdPQ+9FRCDVz9aWGCZwscIS/HDaeurEMEbWwAAvu2ByzoRMN8V5VPc9CV76uS4/RiFi5lhzKjDirq0s16s6cP6Syl/KWeZ+CHmthwtoqj5Do8GfgCIpGWCisjwZQtvF0phP/TaIv4GIpneWceDtE923MWuTjbm84U2kmMoGx9 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 58e6a8a2-f5fc-4cd0-7a19-08d5ee08d4ae x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(5600053)(711020)(2017052603328)(7153060)(7193020); SRVR:TY2PR01MB1897; x-ms-traffictypediagnostic: TY2PR01MB1897: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(85827821059158)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(2016111802025)(20161123564045)(6072148)(6043046)(201708071742011)(7699016); SRVR:TY2PR01MB1897; BCL:0; PCL:0; RULEID:; SRVR:TY2PR01MB1897; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400004)(136003)(376002)(366004)(396003)(346002)(189003)(199004)(53754006)(14444005)(5024004)(256004)(99286004)(790700001)(76176011)(11346002)(6116002)(446003)(9686003)(3846002)(316002)(486006)(102836004)(33656002)(53546011)(476003)(110136005)(26005)(5660300001)(236005)(186003)(7696005)(74482002)(6506007)(6436002)(606006)(68736007)(966005)(25786009)(14454004)(19609705001)(81166006)(6306002)(81156014)(8676002)(2900100001)(55016002)(66066001)(478600001)(39060400002)(8936002)(4326008)(2906002)(53936002)(6246003)(54896002)(74316002)(105586002)(86362001)(7736002)(97736004)(5250100002)(229853002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY2PR01MB1897; H:TY2PR01MB2297.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4DQKvtzijVYiFCCMHHqorjd3BbmcqrLs2ylLqXB9f7Vq+VsR06sufpAX5pYXTRnemTGp5yy9opxziceA0kJcJVgPQ0gDay+3IiFvtyXNyKIbqp6/1fqmuOvy+e2DPxDVC2hcbbrhZJNW/dpMl1ckwSWV1TMO4giEfdDuHAEayqsd4I6fsn1wLZyGs0sOm5dBoV1yVQ8lxo/s36/f6qIG+cO3CrcMVYDocitI19ZsrM33UynGRjPAip12rjZnPdyKhHr3lBe1twr4Zc0XVOUI9lfMrfEV4SqIPR+4lWB6XYDhq42AZfDQjoVvk4SzRR8eaDIUl8kcau+XX8tJxCH6l2l5EmnQB55KdU43lqKFBSc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_TY2PR01MB22971D8FB9BCA1513C3794E9F9510TY2PR01MB2297jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 58e6a8a2-f5fc-4cd0-7a19-08d5ee08d4ae X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 06:20:03.7209 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB1897 X-OrganizationHeadersPreserved: TY2PR01MB1897.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE01PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE01PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 06:20:13 -0000 --_000_TY2PR01MB22971D8FB9BCA1513C3794E9F9510TY2PR01MB2297jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IEZyaWRheSwgSnVseSAyMCwgMjAxOCA3OjQyIEFN DQpUbzogUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+DQpDYzogb2F1 dGggPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWRv cHRpb24gZm9yICJSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAiDQoNCkkgc3VwcG9y dCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQpPbiBUaHUsIEp1bCAxOSwgMjAxOCBhdCA0 OjAxIFBNLCBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 cmlmYWF0LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBhbGwsDQoNClRoaXMgaXMgdGhlIGNh bGwgZm9yIGFkb3B0aW9uIG9mIHRoZSAnUmVzb3VyY2UgSW5kaWNhdG9ycyBmb3IgT0F1dGggMi4w JyBkb2N1bWVudA0KZm9sbG93aW5nIHRoZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlvbiBhdCB0 aGUgTW9udHJlYWwgSUVURiBtZWV0aW5nLg0KDQpIZXJlIGlzIHRoZSBkb2N1bWVudDoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRp Y2F0b3JzLTAyDQoNClBsZWFzZSBsZXQgdXMga25vdyBieSBBdWd1c3QgMm5kIHdoZXRoZXIgeW91 IGFjY2VwdCAvIG9iamVjdCB0byB0aGUNCmFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBz dGFydGluZyBwb2ludCBmb3Igd29yayBpbiB0aGUgT0F1dGgNCndvcmtpbmcgZ3JvdXAuDQoNClJl Z2FyZHMsDQpSaWZhYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGlu dGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlz Y2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55 IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo= --_000_TY2PR01MB22971D8FB9BCA1513C3794E9F9510TY2PR01MB2297jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDvvK3vvLMg44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAx MSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToi QXJpYWwiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo5OS4yNXB0IDMuMGNtIDMuMGNtIDMuMGNtO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mIzQzOzEgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgSnVseSAyMCwgMjAxOCA3OjQyIEFNPGJyPg0KPGI+VG86PC9iPiBSaWZhYXQgU2hl a2gtWXVzZWYgJmx0O3JpZmFhdC5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9h dXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVU SC1XR10gQ2FsbCBmb3IgYWRvcHRpb24gZm9yICZxdW90O1Jlc291cmNlIEluZGljYXRvcnMgZm9y IE9BdXRoIDIuMCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdXBwb3J0 IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMTksIDIwMTggYXQgNDowMSBQTSwgUmlmYWF0 IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5IaSBhbGwsPGJyPg0KPGJyPg0KVGhpcyBpcyB0aGUg Y2FsbCBmb3IgYWRvcHRpb24gb2YgdGhlICdSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAy LjAnIGRvY3VtZW50PGJyPg0KZm9sbG93aW5nIHRoZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlv biBhdCB0aGUgTW9udHJlYWwgSUVURiBtZWV0aW5nLjxicj4NCjxicj4NCkhlcmUgaXMgdGhlIGRv Y3VtZW50Ojxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMiIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxMTU1Q0MiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0 b3JzLTAyPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGJyPg0KPGJy Pg0KUGxlYXNlIGxldCB1cyBrbm93IGJ5IEF1Z3VzdCAybmQgd2hldGhlciB5b3UgYWNjZXB0IC8g b2JqZWN0IHRvIHRoZTxicj4NCmFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGlu ZyBwb2ludCBmb3Igd29yayBpbiB0aGUgT0F1dGg8YnI+DQp3b3JraW5nIGdyb3VwLjxicj4NCjxi cj4NClJlZ2FyZHMsPGJyPg0KUmlmYWF0PC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRo IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1 NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+Q09ORklERU5U SUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHBy aXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50KHMpLg0KIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkg b3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiZuYnNwOyBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUg YXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuPC9zcGFuPjwvaT48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_TY2PR01MB22971D8FB9BCA1513C3794E9F9510TY2PR01MB2297jpnp_-- From nobody Thu Jul 19 23:21:43 2018 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 9BBEA130EE5 for ; Thu, 19 Jul 2018 23:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.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 riT-4XBTyxby for ; Thu, 19 Jul 2018 23:21:33 -0700 (PDT) Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBCB131066 for ; Thu, 19 Jul 2018 23:21:32 -0700 (PDT) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs04.index.or.jp (Postfix) with ESMTP id 78C76472EDF; Fri, 20 Jul 2018 15:21:32 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 139264E0046; Fri, 20 Jul 2018 15:21:32 +0900 (JST) Received: from nriea02.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id w6K6LWom014072; Fri, 20 Jul 2018 15:21:32 +0900 Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea02.index.or.jp with ESMTP id w6K6LVcn014069; Fri, 20 Jul 2018 15:21:31 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w6K6LVDV043933; Fri, 20 Jul 2018 15:21:31 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id w6K6LVbF043932; Fri, 20 Jul 2018 15:21:31 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w6K6LVJa043929; Fri, 20 Jul 2018 15:21:31 +0900 Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM01SA.cu.nri.co.jp (172.59.253.43) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 20 Jul 2018 15:21:30 +0900 Received: from APC01-SG2-obe.outbound.protection.outlook.com (65.55.88.243) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 20 Jul 2018 15:21:30 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gvkoz76bygBoM6lfhCxiRXl7ZkU0VB9g1UUShaFmVHI=; b=F1D8DrmWJVpL0HOuoDqe6MUuaEkJSzTU1CUu1KHALHu6xhUcMKBzYfyR3SjDhyyulJzNp5kDPVXDp3A5PIS9hJzsgO/4d616pTfv3V3fNDLsQ+KhXLlgByOfTw8nWrTL/OweIiLa/VG+EholiRQnkI0R5+HvAI+vXYEYg4m1P/E= Received: from TY2PR01MB2297.jpnprd01.prod.outlook.com (52.133.184.14) by TY2PR01MB2089.jpnprd01.prod.outlook.com (52.133.183.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Fri, 20 Jul 2018 06:21:28 +0000 Received: from TY2PR01MB2297.jpnprd01.prod.outlook.com ([fe80::a80c:6cfe:7925:86f4]) by TY2PR01MB2297.jpnprd01.prod.outlook.com ([fe80::a80c:6cfe:7925:86f4%2]) with mapi id 15.20.0952.022; Fri, 20 Jul 2018 06:21:28 +0000 From: n-sakimura To: Dick Hardt , Rifaat Shekh-Yusef CC: oauth Thread-Topic: [OAUTH-WG] Call for adoption for "Distributed OAuth" Thread-Index: AQHUH5v7xHgfGQvfqEWCEMwVBLmh76SXCvCAgACZfpA= Date: Fri, 20 Jul 2018 06:21:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: 20170719 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [133.250.250.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY2PR01MB2089; 6:FoTS6SMhZJUt/DB8XoK7UCzPRRG4bb2Q5aKIH7a4F2txJytBcn+Fu5JNRCPsoML4jbyyvB5jz498mvyQWI62O8XJU5ADCl8ZoS++GcwIdJkCqL8kcK0Q+8tGEieUVyjxI9vsfS7PDqssv4Th9Yi9XgqO3/7onmQUhcmangIVfwXtNSGkk7NQUaAIg3wBuSSc1LhF9WmBNQig2Xj/kUDGJW4szAliQIIlDLz9GxjNsI6lk5xRT6TVFHZAbJq433Rt1LvoZI9JE52E1DsrQWhljFPUyaBJWQP+v9cYMJESoVraNNj7IPPx6ImRGWQKkhYPo/5EHSSt8RREF+MV5kOSQAtPFZPPjjeg3s2v7CwIuv7tgR8T+FuHDtwMt6fp/wYX7jUCzpHg4UPWBPH4v4tk3+Wx0n1XWbR15lUzgMH9pNmd1sOJBBlEogwWPjjFaUne8O9/I7TGukuRJ+oJLmCBrg==; 5:vf1MCzjYQLYHWCkOvUp/xghEar2LGxP1GQbQXoNQn7tkFSl9z7Ss5aXJYIxqLJHK9HctQLgNT3a8mL0MV06RaYlQTfDQKHt1W2ezZfZnytRcYrclx0LrTkOVJ5yH4zQl2nvLW4MjNzAhYEri/Czmal03Ay4fog6ypPlLZ62EvWo=; 7:x/w0vsGfCx5SY59Uz/O/fN8RfBtIb4BD7ersJVJlLWuQ53sDtkf8nq03opds1sCBj7g4zV/L1hbCoL/m89xHp7gNjlly/0C6eeiQLAW6HwtR5hxEJDNFchPXShmj2mmVinj24MtkWfpSVA21d1MmZS4vq6S6Dh18wRtEo6o4fWGXpH0WHF+VkMmTT9kLcMaZQ4eJu13pormxH4GRlxODYhPh2ZHTiUR3Fzkj3ad6ouzbHTpJXxnu6WUA1M7Toq0D x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ba6cd4db-9842-460f-f701-08d5ee090755 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:TY2PR01MB2089; x-ms-traffictypediagnostic: TY2PR01MB2089: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(85827821059158)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(2016111802025)(20161123564045)(6072148)(6043046)(201708071742011)(7699016); SRVR:TY2PR01MB2089; BCL:0; PCL:0; RULEID:; SRVR:TY2PR01MB2089; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39840400004)(366004)(346002)(136003)(376002)(199004)(189003)(53754006)(186003)(102836004)(74482002)(2906002)(86362001)(54896002)(6306002)(26005)(6436002)(55016002)(68736007)(5660300001)(229853002)(110136005)(53936002)(9686003)(7736002)(39060400002)(66066001)(6116002)(790700001)(97736004)(4326008)(81166006)(236005)(106356001)(105586002)(33656002)(316002)(6246003)(14454004)(446003)(966005)(81156014)(25786009)(3846002)(19609705001)(8676002)(53546011)(6506007)(2900100001)(74316002)(486006)(8936002)(11346002)(5250100002)(7696005)(476003)(256004)(76176011)(478600001)(606006)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:TY2PR01MB2089; H:TY2PR01MB2297.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: 619FIPocz1KbN6GtQ7H15lEGQE/ExqPO19bzMcIpUwHuUww8xT6rr4m713MUrTRqHYAQUpndqdN+eNZGf1Hh2lLtfee29V8ilXxHuDl/o+d7cadREjd5v5fk/KmxprbKtI4UtK9xe3ogaQmuPmyz3HozuZPV5RbVjNs6XH62T8QANc5G/+9SAcmuAaJpSC+MtyMYTq35C7aiKr9VR5GpBqKHQaFpL7T4C2JPuOVhgHHf7nm34OKU3gfE0O+5IlulwEif5iMrXzjq7TEvYnwyIdETUbqqqxhkDoUnF9hKdU0i7FzJOQM+AXYYs2PxZFlBYBE8hwpMAvcPJ0DlMUruOUZdQ5eQ49DexdoLJhiMXZA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_TY2PR01MB229756ABC3B1098A89B11F9DF9510TY2PR01MB2297jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ba6cd4db-9842-460f-f701-08d5ee090755 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 06:21:28.7046 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2089 X-OrganizationHeadersPreserved: TY2PR01MB2089.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 06:21:41 -0000 --_000_TY2PR01MB229756ABC3B1098A89B11F9DF9510TY2PR01MB2297jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIGlmIGl0IHdlcmUgbm90IG9idmlvdXMsIFlFUyDimLoNCg0KRnJvbTogT0F1dGggW21haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGljayBIYXJkdA0KU2VudDog RnJpZGF5LCBKdWx5IDIwLCAyMDE4IDY6MTIgQU0NClRvOiBSaWZhYXQgU2hla2gtWXVzZWYgPHJp ZmFhdC5pZXRmQGdtYWlsLmNvbT4NCkNjOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBhZG9wdGlvbiBmb3IgIkRpc3RyaWJ1dGVkIE9BdXRo Ig0KDQpJJ20gc3VwcG9ydGl2ZS4gOikNCg0KT24gVGh1LCBKdWwgMTksIDIwMTggYXQgNDowNSBQ TSwgUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFh dC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpUaGlzIGlzIHRoZSBjYWxsIGZv ciBhZG9wdGlvbiBvZiB0aGUgJ0Rpc3RyaWJ1dGVkIE9BdXRoJyBkb2N1bWVudA0KZm9sbG93aW5n IHRoZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlvbiBhdCB0aGUgTW9udHJlYWwgSUVURiBtZWV0 aW5nLg0KDQpIZXJlIGlzIHRoZSBkb2N1bWVudDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWhhcmR0LW9hdXRoLWRpc3RyaWJ1dGVkLw0KDQpQbGVhc2UgbGV0IHVzIGtu b3cgYnkgQXVndXN0IDJuZCB3aGV0aGVyIHlvdSBhY2NlcHQgLyBvYmplY3QgdG8gdGhlDQphZG9w dGlvbiBvZiB0aGlzIGRvY3VtZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhl IE9BdXRoDQp3b3JraW5nIGdyb3VwLg0KDQpSZWdhcmRzLA0KSGFubmVzICYgUmlmYWF0DQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_TY2PR01MB229756ABC3B1098A89B11F9DF9510TY2PR01MB2297jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToi77yt77yzIOOCtOOCt+ODg+OCryI7DQoJcGFub3NlLTE6MiAxMSA2IDkg NyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3Jt YWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u b3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLjE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkFy aWFsIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46OTkuMjVwdCAzLjBjbSAzLjBjbSAzLjBjbTt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+QW5kIGlmIGl0IHdlcmUgbm90IG9idmlvdXMsIFlFUw0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPko8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT0F1dGggW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5EaWNrIEhhcmR0PGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAyMCwgMjAxOCA2OjEyIEFNPGJyPg0KPGI+VG86PC9i PiBSaWZhYXQgU2hla2gtWXVzZWYgJmx0O3JpZmFhdC5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8 Yj5DYzo8L2I+IG9hdXRoICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb24gZm9yICZxdW90O0Rpc3RyaWJ1dGVk IE9BdXRoJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gc3VwcG9ydGl2 ZS4gOik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo dSwgSnVsIDE5LCAyMDE4IGF0IDQ6MDUgUE0sIFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5p ZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHRoZSBjYWxs IGZvciBhZG9wdGlvbiBvZiB0aGUgJ0Rpc3RyaWJ1dGVkIE9BdXRoJyBkb2N1bWVudDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zm9sbG93aW5nIHRo ZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlvbiBhdCB0aGUgTW9udHJlYWwgSUVURiBtZWV0aW5n LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I ZXJlIGlzIHRoZSBkb2N1bWVudDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWhhcmR0LW9hdXRoLWRpc3RyaWJ1dGVkLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhcmR0LW9hdXRoLWRpc3RyaWJ1dGVkLzwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UGxlYXNlIGxldCB1cyBrbm93IGJ5IEF1Z3VzdCAybmQgd2hldGhlciB5b3UgYWNjZXB0IC8gb2Jq ZWN0IHRvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+YWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3 b3JrIGluIHRoZSBPQXV0aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+d29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhbm5lcyAmYW1wOyBSaWZhYXQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_TY2PR01MB229756ABC3B1098A89B11F9DF9510TY2PR01MB2297jpnp_-- From nobody Fri Jul 20 00:29:02 2018 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 9B549131026 for ; Fri, 20 Jul 2018 00:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 12fYXOUyxsQf for ; Fri, 20 Jul 2018 00:28:56 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) (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 6E7D0130F08 for ; Fri, 20 Jul 2018 00:28:56 -0700 (PDT) Received: from [80.187.106.183] (helo=[10.159.162.20]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fgPqJ-0004qd-Ia; Fri, 20 Jul 2018 09:28:52 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-8FD162E3-FF8D-4E93-A13C-DF6DB172EC1C; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Fri, 20 Jul 2018 09:28:31 +0200 Cc: Dick Hardt , Rifaat Shekh-Yusef , oauth Content-Transfer-Encoding: 7bit Message-Id: <42FCE1EF-1470-4F29-86D4-8DEFCC823452@lodderstedt.net> References: To: n-sakimura X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 07:29:00 -0000 --Apple-Mail-8FD162E3-FF8D-4E93-A13C-DF6DB172EC1C Content-Type: multipart/alternative; boundary=Apple-Mail-1FE006C3-47D4-43B0-BFF1-E9FAD734CB9C Content-Transfer-Encoding: 7bit --Apple-Mail-1FE006C3-47D4-43B0-BFF1-E9FAD734CB9C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 > Am 20.07.2018 um 08:21 schrieb n-sakimura : >=20 > And if it were not obvious, YES J > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Dick Hardt > Sent: Friday, July 20, 2018 6:12 AM > To: Rifaat Shekh-Yusef > Cc: oauth > Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth" > =20 > I'm supportive. :) > =20 > On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef wrote: > Hi all, > =20 > This is the call for adoption of the 'Distributed OAuth' document > following the positive call for adoption at the Montreal IETF meeting. > =20 > Here is the document: > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ > =20 > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > =20 > Regards, > Hannes & Rifaat > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1FE006C3-47D4-43B0-BFF1-E9FAD734CB9C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

Am 20.07.2= 018 um 08:21 schrieb n-sakimura <= n-sakimura@nri.co.jp>:

And if it were not obvious, YES J

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Friday, July 20, 2018 6:12 AM
To: Rifaat Shekh-Yusef <r= ifaat.ietf@gmail.com>
Cc: oauth <oauth@ietf.org>= ;
Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"

 

I'm supportive. :)

 

On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef &= lt;rifaat.ietf@gm= ail.com> wrote:

Hi all,

 

This is the call for adoption of the 'Distributed OAu= th' document

following the positive call for adoption at the Montr= eal IETF meeting.

 

Here is the document:

 

Please let us know by August 2nd whether you accept /= object to the

adoption of this document as a starting point for wor= k in the OAuth

working group.

 

Regards,

Hannes & Rifaat

 


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

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-1FE006C3-47D4-43B0-BFF1-E9FAD734CB9C-- --Apple-Mail-8FD162E3-FF8D-4E93-A13C-DF6DB172EC1C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyMDA3MjgzMVowIwYJKoZIhvcNAQkEMRYE FHoM0oDeAPeC/fB6qT8Wcdp4tl1LMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQBkoJLqvtBRoY7ahGWxEbp0U/LJ74G7 wIlSLwj7WUFGDhrrWDjpxnM767jk06/zGHWf4zb/k/MSA/6ZnlpYnGJtbSxjhaN/LhzhXSpXXMt7 2WDS3QlnXCU4ijNgdwGJH7RDaXCc1M/3s/jGM6LGdaCfnp6Xed4Cet9qyArKBMaT/dwrVUhq/Mzi tSWntIplFl5XHM9o5O+VbrvwBU4TKPvvJNA7jo9KD7hDvKLdS3cLYxdiw65bI4OxxPYKxutu/kSN 1IOUZVjo1tUiloJ/UyRYcDisXcDl95PledRifr99DIpWiVgQq0sZcvi+JsLjSAn2tkQOz6IOSKK0 hcniQv9mAAAAAAAA --Apple-Mail-8FD162E3-FF8D-4E93-A13C-DF6DB172EC1C-- From nobody Fri Jul 20 00:33:00 2018 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 69D42131067 for ; Fri, 20 Jul 2018 00:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 mPUOiEvW5TKG for ; Fri, 20 Jul 2018 00:32:57 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) (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 32B07130E99 for ; Fri, 20 Jul 2018 00:32:55 -0700 (PDT) Received: from [80.187.106.183] (helo=[10.159.162.20]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fgPuC-0006p4-I6; Fri, 20 Jul 2018 09:32:53 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-9522163F-D372-4BA7-BBDE-314E1079A304; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Fri, 20 Jul 2018 09:32:17 +0200 Cc: Brian Campbell , Rifaat Shekh-Yusef , oauth Content-Transfer-Encoding: 7bit Message-Id: <426DBA0B-CC9B-4D9D-9ED8-5AD779159638@lodderstedt.net> References: To: n-sakimura X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 07:32:58 -0000 --Apple-Mail-9522163F-D372-4BA7-BBDE-314E1079A304 Content-Type: multipart/alternative; boundary=Apple-Mail-3D7D85C9-E71F-4450-B0CC-2787D69A2DB3 Content-Transfer-Encoding: 7bit --Apple-Mail-3D7D85C9-E71F-4450-B0CC-2787D69A2DB3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support adoption of this document. I would like to point out (again) a single resource is not sufficient for mo= st use cases I implemented in the last couple if years. I=E2=80=98m advocati= ng for enhancing the draft to support multiple resources and a clear definit= ion of the relationship between resource(s) and scope. > Am 20.07.2018 um 08:20 schrieb n-sakimura : >=20 > +1 > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell > Sent: Friday, July 20, 2018 7:42 AM > To: Rifaat Shekh-Yusef > Cc: oauth > Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAu= th 2.0" > =20 > I support adoption of this document. > =20 > On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef wrote: > Hi all, >=20 > This is the call for adoption of the 'Resource Indicators for OAuth 2.0' d= ocument > following the positive call for adoption at the Montreal IETF meeting. >=20 > Here is the document: > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 >=20 > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Regards, > Rifaat >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =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 rec= eived 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. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3D7D85C9-E71F-4450-B0CC-2787D69A2DB3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I support adoption of this d= ocument.

I would like to point out (again) a single= resource is not sufficient for most use cases I implemented in the last cou= ple if years. I=E2=80=98m advocating for enhancing the draft to support mult= iple resources and a clear definition of the relationship between resource(s= ) and scope.

Am 20.07.2018 um 08:20 schrieb n-sakimura <n-sakimura@nri.co.jp>:

+1

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef <r= ifaat.ietf@gmail.com>
Cc: oauth <oauth@ietf.org>= ;
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators fo= r OAuth 2.0"

 

I support adoption of this document.

 

On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef &= lt;rifaat.ietf@gm= ail.com> wrote:

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0' doc= ument
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02<= /span>

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat


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

 


CONFIDENTIALIT= Y NOTICE: This email may contain confidential and privileged material for th= e 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 th= e sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-3D7D85C9-E71F-4450-B0CC-2787D69A2DB3-- --Apple-Mail-9522163F-D372-4BA7-BBDE-314E1079A304 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyMDA3MzIxN1owIwYJKoZIhvcNAQkEMRYE FHvx1jv8KGQZW22ddOn4EwMx9QzAMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQASY8l7bLIZNAcxZwCpMakxlqZk/Mj8 ZXUEnzKyvvA8Ko3Y6iTVWfkeve2u4ZYiZn2abruWQriVTPctilBLn1N8o0U/h5o3v0eVgkznErW2 hTGxkSFNGTmL+qiLp3BUx7hlO9txYdZdpVtj3bdRv+l62XqW8jAsVm4t2jM3AtJ3nptl+ATeqUOO R5zvSfkKdMJ0q5Prsn9t75SkfNo2wPa280z9eLmYJY6xZSIohOpIz1EAvAKyEHUDqJ5LxTEjj8Ee INQze+It3JJ1VCNKHWCv7RBF8FfvLcAMaZflHMo0MdCWm+BUhBVXHyrUpdLJrxXRjAM04k1+OGk+ C15YKgrTAAAAAAAA --Apple-Mail-9522163F-D372-4BA7-BBDE-314E1079A304-- From nobody Fri Jul 20 00:43:37 2018 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 3B39413107D for ; Fri, 20 Jul 2018 00:43:35 -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 8iO9wt-i2M3W for ; Fri, 20 Jul 2018 00:43:32 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 6DD32131071 for ; Fri, 20 Jul 2018 00:43:32 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id b15-v6so19711750oib.10 for ; Fri, 20 Jul 2018 00:43:32 -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=W3744Eh21XfcHSVH/VD/hbnVLJLK79Es7BwRGbZANiA=; b=YjMcsH9DKEMd9mMQDMEaRHnPsZARYJJFA2OdNV89pZ/DYklBRzraN5sZw+2gQs+R21 Yi4OTPaSl0nUEIb66ltsHWX1eXHGfEO8ThHWuGyfms7Kn9QaQSOjHVs4Qc8pXo66Mk13 V+ooyBYEY+hudLKG/pIY3tRb/v7IJ2zsDTh2iSl9+jfOsyDFqSrzNyOJXJiUxeVusaQ9 7JbhSCrPzxYeEHVaTSw+kdvFhc/HQY498BqIynEttPQO+Zndo9MkviYokM02rvVifYYH MSknEpfabQ3AgoCel4ONlgI3/AhpP7uaUcMPeShYYDfbMz4xbgMobOj6gJi++/trN7dX 0ZLQ== 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=W3744Eh21XfcHSVH/VD/hbnVLJLK79Es7BwRGbZANiA=; b=f4S6v5brRfDO90vmsFOZDMa6MUL8kQGnSy08k8ts33wvZqaYTMYHcCmomcTiHQZBPE GTGBVPOIXjdAF06DEwx09nwa/UraG7L5nJzIJJ+knWG/AumDAP60FUigZMy+2fTeyWNS R2AjsjomFFD03EJLtxYswpONw0hwrCB09YCvTBSctaW/Zec36uBNycjsntm8sijHKbMs B0kxGEeSOyEnSKL1j2KfSedWo7QD2hGpZfherl6eCFR4PaPngbIEUQYZQ/pFtTbdH76z YLW8lsgVU53YkEomu4mk8XuDTIsL3JMwWDXpAIPa7v1Zf/tsS0gx5toeS5/u8xInB+kp kXjA== X-Gm-Message-State: AOUpUlEKtPLUhknI73+666Wkc3iEMmhBOT48nhucae8h9IsqfRfxNbhT vTWdeXyU0caPW1IA80qJlUTO4XL/V6/4TmXyZg== X-Google-Smtp-Source: AAOMgpdmvVRWzgG/HIUXcckb7eDb2fB9OWkcxCUSjVESYtQWp6n1sgBc0N/WDB+SKKskxv9Ar1lH9g53FikreNDNn+c= X-Received: by 2002:aca:eb0d:: with SMTP id j13-v6mr1051702oih.304.1532072611562; Fri, 20 Jul 2018 00:43:31 -0700 (PDT) MIME-Version: 1.0 References: <426DBA0B-CC9B-4D9D-9ED8-5AD779159638@lodderstedt.net> In-Reply-To: <426DBA0B-CC9B-4D9D-9ED8-5AD779159638@lodderstedt.net> From: Filip Skokan Date: Fri, 20 Jul 2018 09:43:20 +0200 Message-ID: To: Torsten Lodderstedt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c848d7057169732b" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 07:43:35 -0000 --000000000000c848d7057169732b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten, > Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at multiple resource servers. That's already in. Furthermore what about logical names for target services? Like was added in -03 of token exchange? Best, *Filip Skokan* On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt wrote: > I support adoption of this document. > > I would like to point out (again) a single resource is not sufficient for > most use cases I implemented in the last couple if years. I=E2=80=98m adv= ocating > for enhancing the draft to support multiple resources and a clear > definition of the relationship between resource(s) and scope. > > Am 20.07.2018 um 08:20 schrieb n-sakimura : > > +1 > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Brian Campbell > *Sent:* Friday, July 20, 2018 7:42 AM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for > OAuth 2.0" > > > > I support adoption of this document. > > > > On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef > wrote: > > Hi all, > > This is the call for adoption of the 'Resource Indicators for OAuth 2.0' > document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Regards, > Rifaat > > > _______________________________________________ > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000c848d7057169732b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Torsten,

>=C2=A0Multip= le "resource" parameters may be used to indicate that the issued = token is intended to be used at multiple resource servers.

That's already in. Furthermore what about logical names for ta= rget services? Like was added in -03 of token exchange?

Best,
Filip Skoka= n


= On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
I support ado= ption of this document.

I would like to point out = (again) a single resource is not sufficient for most use cases I implemente= d in the last couple if years. I=E2=80=98m advocating for enhancing the dra= ft to support multiple resources and a clear definition of the relationship= between resource(s) and scope.

Am 20.07.2018 um 08:20 schrie= b n-sakimura <= n-sakimura@nri.co.jp>:

+1

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf= Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicat= ors for OAuth 2.0"

=C2=A0

I support adoption of this document. <= /p>

=C2=A0

On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef = <rifaat.ietf@= gmail.com> wrote:

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-= 02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat


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

=C2=A0


CONFIDENTIAL= ITY 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..=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 attach= ments from your computer. Thank you.

___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth
<= /div>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c848d7057169732b-- From nobody Fri Jul 20 01:33:33 2018 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 85A3B130E98 for ; Fri, 20 Jul 2018 01:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.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 qZxzA6trAssc for ; Fri, 20 Jul 2018 01:33:28 -0700 (PDT) Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA10131074 for ; Fri, 20 Jul 2018 01:33:24 -0700 (PDT) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs01.index.or.jp (Postfix) with ESMTP id 44E7A77EF5; Fri, 20 Jul 2018 17:33:24 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id DF90D4E0046; Fri, 20 Jul 2018 17:33:23 +0900 (JST) Received: from nriea04.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id w6K8XNGF030647; Fri, 20 Jul 2018 17:33:23 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea04.index.or.jp with ESMTP id w6K8XN37030646; Fri, 20 Jul 2018 17:33:23 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w6K8XNO8043259; Fri, 20 Jul 2018 17:33:23 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id w6K8XN8B043256; Fri, 20 Jul 2018 17:33:23 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w6K8XNZT043252; Fri, 20 Jul 2018 17:33:23 +0900 Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM01SA.cu.nri.co.jp (172.59.253.43) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 20 Jul 2018 17:33:22 +0900 Received: from APC01-PU1-obe.outbound.protection.outlook.com (65.55.88.23) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 20 Jul 2018 17:33:21 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K0L/aCZd56GJif8ehop6zKo2omvRi/AQ9oBu3QjypfQ=; b=SzAN+Swk4mPR+kV4tG3Ju7Y4wSZqsJ3K/dP/S246HVlV6YgNdlBoP8lh3OM5M3+oJNVd9BiiWtMEvTQiI6nAD9KE9tuxLKcuCXF8RiQTQOMnFXjPe2nnHP22Eayh6JhCwdu9Y9E5AZdxgj0kbBgnFqS+WRsMnYCgjZOClu83JVQ= Received: from TY2PR01MB2297.jpnprd01.prod.outlook.com (52.133.184.14) by TY2PR01MB3227.jpnprd01.prod.outlook.com (20.177.100.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.20; Fri, 20 Jul 2018 08:33:19 +0000 Received: from TY2PR01MB2297.jpnprd01.prod.outlook.com ([fe80::a80c:6cfe:7925:86f4]) by TY2PR01MB2297.jpnprd01.prod.outlook.com ([fe80::a80c:6cfe:7925:86f4%2]) with mapi id 15.20.0952.022; Fri, 20 Jul 2018 08:33:19 +0000 From: n-sakimura To: David Waite , Dick Hardt CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] updated Distributed OAuth ID Thread-Index: AQHUAoOaSSHKxrUFgUqarOSvA9w6jaSWZocAgAGYHwA= Date: Fri, 20 Jul 2018 08:33:19 +0000 Message-ID: References: <1AD25F21-4F76-41CA-96E8-6E09373D04E8@alkaline-solutions.com> In-Reply-To: <1AD25F21-4F76-41CA-96E8-6E09373D04E8@alkaline-solutions.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: 20170719 authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [133.250.250.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY2PR01MB3227; 6:Gzd21+oGyg69KY8HPPa2JXucFq6dlTBvfHdwHctrDuWf7sZFif5otVz3BmCQtkDCU9mmdqOjcOPFUc3P9im1kOiHWXhe4WdjLaK1t4Q/QGONorFhZhyDYcVhZG5E8p3HoYCox7EPfjow4krNHrmtv6Gzt4BHl+utli8zQpHpUm2psNW2b2pOhhbYObyZjtLmStS9bmOlnUGWLyrAU6M9slMP4waxgHOWyprffz8KutIcM4McDFtgAaDZkUibhnArnn+qTtUvUTRGUFLThSi3Es/NA3RRb5fREWW4c97DSS6pfO0UJzJiBxuai7vfMN9IQV/QJkv8hS2VKyOUkKRwBlTIoL5miMmF7n+zrNRuPos1rYDmzhaR4mvwcWwibRSvWnrdD8t7sbHDLyVeW1kXxXkHBkfQtXPaDgK5yUpDrzYXCVmCeJgsdW0coZmkbxyq25HQ09etjeIVjMZnPGnsOA==; 5:5YndP8kQZRatVDOt+LjLfgkruYxKegrxKmcl0e2Kou8IIS5ukI+hKQyT8YAiVhP0wJcqjsb+Fkg4HQUrxgru7r3FZrdL1gNAVU9wMk4jwR/r010f14G25GC3JfRx9y0efHs7szk5yoEzNNrWDCjn7qtV6YvUXDMeNJ6ncyj+7Bk=; 7:+EKFfiyq+pgNLJioCNVBTIal6LvXN/raxC19k0M8sPmGl+A9OxjE0mvYUCxatUxH41Yr3tpBOvZJ1L0hsaWW2TFpvcjxxb8cW93W2k1FTkf99biydwzJs7S/Px/8oLbOuVc/AavSzrzSXs+kTPcmedfzI6viKItakzRjcCOi+qMSm1bB6BTx5oBZBNWxf8Fzz3VjRQgWiUv7oIm02xaccWmNfiYkezsVHhgsln5Qf066SIJqHWAfuX8tiQBqo/We x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7ae9f7b4-dcbd-4329-82e8-08d5ee1b72a6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:TY2PR01MB3227; x-ms-traffictypediagnostic: TY2PR01MB3227: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(120809045254105)(85827821059158)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123564045)(2016111802025)(20161123558120)(20161123560045)(20161123562045)(6043046)(6072148)(201708071742011)(7699016); SRVR:TY2PR01MB3227; BCL:0; PCL:0; RULEID:; SRVR:TY2PR01MB3227; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(366004)(39840400004)(136003)(376002)(199004)(189003)(51914003)(25786009)(2900100001)(4326008)(2420400007)(8936002)(15650500001)(3846002)(790700001)(6116002)(105586002)(6246003)(81156014)(106356001)(8676002)(81166006)(256004)(11346002)(7736002)(476003)(14444005)(19609705001)(486006)(2906002)(5660300001)(74316002)(10710500007)(39060400002)(53936002)(229853002)(9686003)(6306002)(236005)(5250100002)(6436002)(54896002)(86362001)(99286004)(316002)(55016002)(966005)(33656002)(110136005)(14454004)(66066001)(478600001)(26005)(102836004)(186003)(7696005)(446003)(53546011)(76176011)(6506007)(97736004)(68736007)(7110500001)(9326002)(606006)(74482002); DIR:OUT; SFP:1102; SCL:1; SRVR:TY2PR01MB3227; H:TY2PR01MB2297.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: eyWs1qYBXDUkUNWK1iITK2Q092uCkRWvOXI16pfvJ0xl5UYZzQ0UXUmN2eWWn5OEonA8M5blwxWHCrvuWzharv3Z7MjdTErrok+Ft7lW75utvLdE54GJeLADxeCSohi1FC5QT3svmJ8ZWtUsuKI9AmtnHfGowSQQZ6DAagolaViTyrvj/1tdMjuQHEtheF+6DHU6kKPUIOWSP5KLZ0deQ+5asAGdaulW3d5q/+UG+r3MTv6BDniaKpv+NZPoV+pVwO48bpfamVfr54QxtCCqAUzHZWUUKKZN216FkJCxU7DfQk++XqU+5gYk7/YVlLMsPxp194krorkNrv9nzBTIeiq+80HqI9qr9QmLAd9ZYbE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_TY2PR01MB2297DBA5677C67441221DF54F9510TY2PR01MB2297jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7ae9f7b4-dcbd-4329-82e8-08d5ee1b72a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 08:33:19.7367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB3227 X-OrganizationHeadersPreserved: TY2PR01MB3227.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 08:33:32 -0000 --_000_TY2PR01MB2297DBA5677C67441221DF54F9510TY2PR01MB2297jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnQsIGFuZCBzb3JyeSBmb3IgdGhlIGRl bGF5IGluIG15IHJlcGx5Lg0KDQpEb2luZyBpdCB3aXRoIFdlYiBMaW5raW5nIFtSRkM4Mjg4XSAg aGFzIHNldmVyYWwgYWR2YW50YWdlcy4NCg0KDQogIDEuICBJdCBpcyBzdGFuZGFyZCBiYXNlZCDi mLogSXQgaXMganVzdCBhIG1hdHRlciBvZiByZWdpc3RlcmluZyBsaW5rIHJlbGF0aW9ucyB0byB0 aGUgSUFOQSBMaW5rIFJlbGF0aW9uIFR5cGUgUmVnaXN0cnksIGFuZCBpdCBpcyBxdWl0ZSB3aWRl bHkgdXNlZC4NCiAgMi4gIE5vIG9yIHZlcnkgbGl0dGxlIGNvZGluZyBuZWVkZWQ6IE90aGVyIHRo YW4gYWRkaW5nIHNvbWUgSFRUUCBzZXJ2ZXIgY29uZmlndXJhdGlvbiwgdGhlIHJlc3Qgc3RheXMg dGhlIHNhbWUgYXMgUkZDNjc1MC4NCiAgMy4gIFN0YW5kYXJkIGludGVyZmFjZTogdGhpcyBraW5k IG9mIG1ldGFkYXRhIGlzIGFwcGxpY2FibGUgbm90IG9ubHkgZm9yIGxldHRpbmcgdGhlIGNsaWVu dCBmaW5kIHRoZSBhcHByb3ByaWF0ZSBhdXRob3JpemF0aW9uIHNlcnZlciBidXQgZm9yIG90aGVy IG1ldGFkYXRhIGFzIHdlbGwuIEFsc28sIG90aGVyIGVuZHBvaW50cyBhcyBsb25nIGFzIGl0IGlz IHN1cHBvcnRpbmcgdGhlIGRpcmVjdCBjb21tdW5pY2F0aW9uIHdpdGggdGhlIGNsaWVudCwgY2Fu IHByb3ZpZGUgcmVsZXZhbnQgbWV0YWRhdGEgd2l0aCBpdCB3aXRob3V0IGdvaW5nIHRocm91Z2gg dGhlIGNsaWVudCBhdXRob3JpemF0aW9uLg0KDQpJIGRpZCBub3QgcXVpdGUgZm9sbG93IHdoeSBD T1JTIGlzIHJlbGV2YW50IGhlcmUuIFdlIGFyZSBqdXN0IHRhbGtpbmcgYWJvdXQgdGhlIGNsaWVu dCB0byBzZXJ2ZXIgY29tbXVuaWNhdGlvbiwgYW5kIHRoZXJlIGFyZSBubyBlbWJlZGRlZCByZXNv dXJjZXMgaW4gdGhlIHJlc3BvbnNlLiBDb3VsZCB5b3Uga2luZGx5IGVsYWJvcmF0ZSBhIGxpdHRs ZSwgcGxlYXNlPw0KDQpGb3IgdGhlIHNlY29uZCBwb2ludCwgc2luY2UgaXQgd2FzIGRpc2N1c3Nl ZCBpbiB0aGUgV0cgbWVldGluZyB5ZXN0ZXJkYXksIEkgd2lsbCBkZWZlciB0byB0aGF0IGRpc2N1 c3Npb24uDQoNCkJlc3QsDQoNCk5hdCBTYWtpbXVyYQ0KDQoNCkZyb206IE9BdXRoIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmlkIFdhaXRlDQpTZW50OiBU aHVyc2RheSwgSnVseSAxOSwgMjAxOCA0OjU1IFBNDQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJk dEBnbWFpbC5jb20+DQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IHVwZGF0ZWQgRGlzdHJpYnV0ZWQgT0F1dGggSUQNCg0KRm91ciBjb21tZW50cy4NCg0KRmlyc3Q6 IFdoYXQgaXMgdGhlIHJhdGlvbmFsZSBmb3IgaW5jbHVkaW5nIHRoZSBwYXJhbWV0ZXJzIGFzIExp bmsgaGVhZGVycyByYXRoZXIgdGhhbiBwYXJ0IG9mIHRoZSBXV1ctQXV0aGVudGljYXRlIGNoYWxs ZW5nZSwgZS5nLjoNCg0KV1dXLUF1dGhlbnRpY2F0ZTogQmVhcmVyIHJlYWxtPSJleGFtcGxlX3Jl YWxtIiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2NvcGU9ImV4YW1wbGVfc2NvcGUi LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlcnJvcj3igJxpbnZhbGlkX3Rva2VuIiwN CiAgICByZXNvdXJjZV91cmk9Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL3Jlc291cmNlIiwNCiAg ICBvYXV0aF9zZXJ2ZXJfbWV0YWRhdGFfdXJpcz0iaHR0cHM6Ly9hcy5leGFtcGxlLmNvbS8ud2Vs bC1rbm93bi9vYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlciBodHRwczovL2RpZmZlcmVudC1hcy5l eGFtcGxlLmNvbS8ud2VsbC1rbm93bi9vYXV0aC1hdXRob3JpemF0aW9uLXNlcnZlciINCg0KTXkg dW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBSRkM2NzUwIGF1dGgtcGFyYW1zIGFyZSBleHRlbnNp YmxlIChidXQgbm90IGN1cnJlbnRseSBwYXJ0IG9mIGFueSBtYW5hZ2VkIHJlZ2lzdHJ5LikNCg0K T25lIHJlYXNvbiB0byBnbyB3aXRoIHRoaXMgdnMgTGluayBoZWFkZXJzIGlzIENPUlMgcG9saWN5 IC0gZXhwb3NpbmcgTGluayBoZWFkZXJzIHRvIGEgcmVtb3RlIGNsaWVudCBtdXN0IGJlIGRvbmUg YWxsIG9yIG5vdGhpbmcgYXMgcGFydCBvZiB0aGUgQ09SUyBwb2xpY3ksIGFuZCBjYW7igJl0IGJl IGxpbWl0ZWQgYnkgdGhlIGtpbmQgb2YgbGluay4NCg0KU2Vjb25kOiAocmV0YWluaW5nIGxpbmsg Zm9ybWF0KSBJcyB0aGVyZSBhIHJlYXNvbiB0aGUgbWV0YWRhdGEgbG9jYXRpb24gaXMgc3BlY2lm aWVkIHRoZSB3YXkgaXQgaXM/IEl0IHNlZW1zIGxpa2UNCg0KPGh0dHBzOi8vYXMuZXhhbXBsZS5j b20vLndlbGwta25vd24vb2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2ZXI+OyByZWw94oCcb2F1dGhf c2VydmVyX21ldGFkYXRhX3VyaSINCg0Kc2hvdWxkIGJlDQoNCjxodHRwczovL2FzLmV4YW1wbGUu Y29tPjsgcmVsPeKAnG9hdXRoX2lzc3VlciINCg0KT0F1dGggZGVmaW5lcyB0aGUgbG9jYXRpb24g b2YgbWV0YWRhdGEgdW5kZXIgdGhlIC53ZWxsLWtub3duIGVuZHBvaW50IGFzIGEgTVVTVC4gQW4g ZXh0ZW5zaW9uIG9mIE9BdXRoIG1heSBjaG9vc2UgZnJvbSBhdCBsZWFzdCB0aHJlZSBkaWZmZXJl bnQgbWV0aG9kcyBmb3IgaGFuZGxpbmcgZXh0ZW5zaW9ucyBiZXlvbmQgdGhpczoNCjEuIEFkZCBh ZGRpdGlvbmFsIGtleXMgdG8gdGhlIG9hdXRoLWF1dGhvcml6YXRpb24tc2VydmVyIG1ldGFkYXRh DQoyLiBBZGQgYWRkaXRpb25hbCByZXNvdXJjZXMgdG8gLndlbGwta25vd24gZm9yIGNsaWVudHMg dG8gc3VwcG9ydGluZyB0aGVpciBleHRlbnNpb25zIHRvIGF0dGVtcHQgdG8gcmVzb2x2ZSwgdHJl YXRpbmcg4oCYcmVndWxhcuKAmSBPQXV0aCBhcyBhIGZhbGxiYWNrLg0KMy4gRGVmaW5lIHRoZWly IG93biBwYXJhbWV0ZXIsIHN1Y2ggYXMgcmVsPeKAnHNwZWNpYWxhdXRoX2lzc3VlcuKAnSwgcG90 ZW50aWFsbHkgdXNpbmcgYSBkaWZmZXJlbnQgbWVjaGFuaXNtIGZvciBzcGVjaWZ5aW5nIG1ldGFk YXRhDQoNCkdpdmVuIGFsbCB0aGlzLCBpdCBzZWVtcyBhcHByb3ByaWF0ZSB0byBvbmx5IHN1cHBv cnQgc3BlY2lmeWluZyBvZiBtZXRhZGF0YS1zdXBwbHlpbmcgaXNzdWVycywgbm90IG1ldGFkYXRh IHVyaXMuDQoNClRoaXJkOiBJIGhhdmUgZG91YnRzIG9mIHRoZSB1c2VmdWxuZXNzIG9mIHJlc291 cmNlX3VyaSBpbiBwYXJhbGxlbCB0byBib3RoIHRoZSBjbGllbnQgcmVxdWVzdGVkIFVSSSBhbmQg dGhlIEF1dGhvcml6YXRpb24g4oCccmVhbG3igJ0gcGFyYW1ldGVyLg0KDQpBcyBjdXJyZW50bHkg ZGVmaW5lZCwgdGhlIGNsaWVudCB3b3VsZCBiZSB0aGUgb25lIGVuZm9yY2luZyAob3IgcG9zc2li bHkgaWdub3JpbmcpIHN0YXRpYyBwb2xpY3kgYXJvdW5kIHJlc291cmNlIFVSSXMgLSB0aGF0IGEg cmVzb3VyY2UgVVJJIGlzIGFyYml0cmFyeSBleGNlcHQgaW4gdGhhdCBpdCBtdXN0IG1hdGNoIHRo ZSBob3N0IChhbmQgc2NoZW1lL3BvcnQ/KSBvZiB0aGUgcmVxdWVzdGVkIFVSSS4gVGhlIGluZm9y bWF0aW9uIG9uIHRoZSByZXF1ZXN0ZWQgVVJJIGJ5IHRoZSBjbGllbnQgaXMgbm90IHNoYXJlZCBi ZXR3ZWVuIHRoZSBjbGllbnQgYW5kIEFTIGZvciBpdCB0byBkbyBpdHMgb3duIHBvbGljeSB2ZXJp ZmljYXRpb24uIEl0IHdvdWxkIHNlZW0gYmV0dGVyIHRvIHNlbmQgdGhlIGNsaWVudCBvcmlnaW4g dG8gdGhlIEFTIGZvciBpdCB0byBkbyAocG90ZW50aWFsKSBwb2xpY3kgdmVyaWZpY2F0aW9uLCBy YXRoZXIgdGhhbiByZWx5aW5nIG9uIGNsaWVudHMgdG8gaW1wbGVtZW50IGl0IGZvciB0aGVtIGJh c2VkIG9uIHN0YXRpYyBzcGVjIHBvbGljeS4NCg0KVGhlIG5hbWUg4oCccmVzb3VyY2UgVVJJ4oCd IGlzIGFsc28gY29uZnVzaW5nLCBhcyBJIHdvdWxkIGV4cGVjdCBpdCB0byBiZSB0aGUgVVJJIHRo YXQgd2FzIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LiBUaGUgcHVycG9zZSBvZiB0aGlzIHBhcmFt ZXRlciBpcyBhIGJpdCBjb25mdXNpbmcsIGFzIGl0IGlzIG9ubHkgZGVmaW5lZCBhcyDigJxBbiBP QXV0aCAyLjAgUmVzb3VyY2UgRW5kcG9pbnQgc3BlY2lmaWVkIGluIFtSRkM2NzUwXSBzZWN0aW9u IDMuMiAtIHdoZXJlIHRoZSB0ZXJtIGRvZXNu4oCZdCBhcHBlYXIgaW4gNjc1MCBhbmQgdGhlcmUg ZG9lcyBub3QgYXBwZWFyIHRvIGJlIGEgc2VjdGlvbiAzLjIgOy0pDQoNCkl0IHNlZW1zIHRoYXQ6 DQphLiBJZiB0aGUgcmVzb3VyY2VfdXJpIGlzIGEgZGlyZWN0IG1hdGNoIGZvciB0aGUgVVJJIHJl cXVlc3RlZCBmb3IgdGhlIGNsaWVudCwgaXQgaXMgcmVkdW5kYW50IGFuZCBzaG91bGQgYmUgZHJv cHBlZA0KICAgIChJZiB0aGUgcmVzb3VyY2UgVVJJIGlzICpub3QqIGEgZGlyZWN0IG1hdGNoIHdp dGggdGhlIFVSSSBvZiB0aGUgcmVzb3VyY2UgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQsIGl0IG1p Z2h0IG5lZWQgYSBiZXR0ZXIgbmFtZSkuDQpiLiBJZiB0aGUgcmVzb3VyY2UgVVJJIGlzIG1lYW50 IHRvIHByb3ZpZGUgYSBjZXJ0YWluIGFyYml0cmFyeSBncm91cGluZyBmb3IgYXBwbHlpbmcgdG9r ZW5zIHdpdGhpbiB0aGUgb3JpZ2luIG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIsIHdoYXQgaXMgaXRz IHZhbHVlIG92ZXIgdGhlIHByZWV4aXN0aW5nIOKAnCByZWFsbeKAnSBwYXJhbWV0ZXI/DQpjLiBJ ZiB0aGUgcmVzb3VyY2UgVVJJIGlzIG1lYW50IHRvIHByb3ZpZGUgYSB3YXkgZm9yIGFuIEFTIHRv IGFsbG93IHJlc291cmNlcyB0byBiZSBpbmRlcGVuZGVudCwgaWRlbnRpZmllZCBlbnRpdGllcyBv biBhIHNpbmdsZSBvcmlnaW4gLSBJ4oCZbSB1bnN1cmUgaG93IGEgY2xpZW50IHdvdWxkIHVuZGVy c3RhbmQgaXQgaXMgbWVhbnQgdG8gdHJlYXQgdGhlc2UgcmVzb3VyY2UgVVJJcyBhcyBpbmRlcGVu ZGVudCBlbnRpdGllcyAoZS5nLiBiZSBzdXJlIG5vdCB0byBzZW5kIGJlYXJlciB0b2tlbnMgbWlu dGVkIGZvciByZXNvdXJjZSAvZW50aXR5MSB0byAvZW50aXR5Miwgb3IgZm9yIHRoYXQgbWF0dGVy IHByZXZlbnQgL2VudGl0eTEgZnJvbSByZXF1ZXN0aW5nIHRva2VucyBmb3IgL2VudGl0eTIpLg0K DQpBZG1pdHRlZGx5IGJhc2VkIG9uIG5vdCBmdWxseSB1bmRlcnN0YW5kaW5nIHRoZSBwdXJwb3Nl IG9mIHRoaXMgcGFyYW1ldGVyLCBpdCBzZWVtcyB0byBtZSB0aGVyZSBleGlzdHMgYSBzaW1wbGVy IGZsb3cgd2hpY2ggYmV0dGVyIGxldmVyYWdlcyB0aGUgZXhpc3RpbmcgQXV0aGVudGljYXRpb24g bWVjaGFuaXNtIG9mIEhUVFAuDQoNCkEgcmVxdWVzdCB3b3VsZCBmYWlsIGR1ZSB0byBhbiBpbnZh bGlkIG9yIG1pc3NpbmcgdG9rZW4gZm9yIHRoZSByZWFsbSBhdCB0aGUgb3JpZ2luLCBhbmQgYW5k IHRoZSBjbGllbnQgd291bGQgbWFrZSBhIHJlcXVlc3QgdG8gdGhlIGlzc3VlciBpbmNsdWRpbmcg dGhlIG9yaWdpbiBvZiB0aGUgcmVxdWVzdGVkIHJlc291cmNlIGFzIGEgcGFyYW1ldGVyLiBBbnkg b3RoZXIgaW5jbHVkZWQgcGFyYW1ldGVycyBzcGVjaWZpZWQgYnkgdGhlIFdXVy1BdXRoZW50aWNh dGUgY2hhbGxlbmdlIHVuZGVyc3Rvb2QgYnkgdGhlIGNsaWVudCAoc3VjaCBhcyDigJxzY29wZeKA nSkgd291bGQgYWxzbyBiZSBhcHBsaWVkIHRvIHRoaXMgcmVxdWVzdC4NCg0KTm9ybWFsIGF1dGhv cml6YXRpb24gZ3JhbnQgZmxvdyB3b3VsZCB0aGVuIGhhcHBlbiAoYXMgdGhpcyBpcyB0aGUgb25s eSBncmFudCB0eXBlIHN1cHBvcnRlZCBieSBSRkM2NzUwKS4gT25jZSB0aGUgYWNjZXNzIHRva2Vu IGlzIGFjcXVpcmVkIGJ5IHRoZSBjbGllbnQsIHRoZSBjbGllbnQgYXNzb2NpYXRlcyB0aGF0IHRv a2VuIHdpdGggdGhlIOKAnHJlYWxt4oCdIHBhcmFtZXRlciBnaXZlbiBpbiB0aGUgaW5pdGlhbCBj aGFsbGVuZ2UgYnkgdGhlIHJlc291cmNlIHNlcnZlciBvcmlnaW4uIExpa2V3aXNlLCB0aGUg4oCY YXVk4oCZIG9mIHRoZSB0b2tlbiBhcyByZXR1cm5lZCBieSBhIHRva2VuIGludHJvc3BlY3Rpb24g cHJvY2VzcyB3b3VsZCBiZSB0aGUgb3JpZ2luIG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIuDQoNCkl0 IHNlZW1zIGFueSBtb3JlIGNvbXBsaWNhdGVkIHByb3RlY3RlZCByZXNvdXJjZSBncm91cGluZ3Mg b24gYSByZXNvdXJjZSBzZXJ2ZXIgd291bGQgbmVlZCBhIGNsaWVudCB0byB1bmRlcnN0YW5kIHRo ZSBzdHJ1Y3R1cmUgb2YgdGhlIHJlc291cmNlIHNlcnZlciwgYW5kIHRodXMgZmV0Y2ggc29tZSBz b3J0IG9mIHJlc291cmNlIHNlcnZlciBtZXRhZGF0YS4NCg0KRm91cnRoIGFuZCBmaW5hbGx5OiBJ cyB0aGUgaW50ZW50aW9uIHRvIGV2ZW50dWFsbHkgcmVjb21tZW5kIHRva2VuIGJpbmRpbmcgaGVy ZT8gVG9rZW4gYmluZGluZyBhcyBhIHJlcXVpcmVtZW50IGFjcm9zcyBjbGllbnRzLCByZXNvdXJj ZXMsIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHdvdWxkIGlzb2xhdGUgdG9rZW5zIHRv IG9ubHkgYmVpbmcgY29uc3VtZWQgd2l0aGluIGFuIG9yaWdpbi4gVGhpcyB3b3VsZCBhY3R1YWxs eSBtYWtlIHJlZHVuZGFudC9zdXBwbGVtZW50YWwgdGhlIEFTIGFkZGl0aW9ucyBkZWZpbmVkIHdp dGhpbiB0aGlzIHNwZWMgKHJlc291cmNlL29yaWdpbiByZXF1ZXN0IHBhcmFtZXRlciwg4oCYYXVk 4oCZIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgbWVtYmVyKQ0KDQotRFcNCg0KDQpPbiBKdW4gMTIs IDIwMTgsIGF0IDE6MjggUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0 bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIZXkgT0F1dGggV0cNCg0KSSBoYXZl IHdvcmtlZCB3aXRoIE5hdCBhbmQgQnJpYW4gdG8gbWVyZ2Ugb3VyIGNvbmNlcHRzIGFuZCB0aG9z ZSBhcmUgY2FwdHVyZWQgaW4gdGhlIHVwZGF0ZWQgZHJhZnQuDQoNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhcmR0LW9hdXRoLWRpc3RyaWJ1dGVkLw0KDQpXZSBhcmUg aG9wZWZ1bCB0aGUgV0cgd2lsbCBhZG9wdCB0aGlzIGRyYWZ0IGFzIGEgV0cgZG9jdW1lbnQuDQoN CkFueSBjb21tZW50cyBhbmQgZmVlZGJhY2sgYXJlIHdlbGNvbWUhDQoNCi9EaWNrDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_TY2PR01MB2297DBA5677C67441221DF54F9510TY2PR01MB2297jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToi77yt77yzIOOCtOOCt+ODg+OCryI7DQoJcGFub3NlLTE6MiAxMSA2IDkg NyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLjE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo5OS4yNXB0IDMuMGNtIDMuMGNtIDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTc1MTczMzQzMTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6NTc1NDE1ODYgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5IaSBEYXZpZCwgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBm b3IgdGhlIGNvbW1lbnQsIGFuZCBzb3JyeSBmb3IgdGhlIGRlbGF5IGluIG15IHJlcGx5Lg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Eb2luZyBpdCB3aXRoIFdlYiBMaW5raW5n IFtSRkM4Mjg4XSAmbmJzcDtoYXMgc2V2ZXJhbCBhZHZhbnRhZ2VzLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPkl0IGlzIHN0YW5kYXJkIGJhc2VkDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OldpbmdkaW5ncyI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+IEl0IGlzIGp1c3QgYSBtYXR0ZXIgb2YgcmVnaXN0ZXJp bmcgbGluayByZWxhdGlvbnMgdG8gdGhlIElBTkEgTGluayBSZWxhdGlvbiBUeXBlIFJlZ2lzdHJ5 LCBhbmQgaXQgaXMgcXVpdGUgd2lkZWx5IHVzZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPk5vIG9yIHZlcnkgbGl0dGxlIGNvZGluZyBuZWVkZWQ6IE90aGVyIHRo YW4gYWRkaW5nIHNvbWUgSFRUUCBzZXJ2ZXIgY29uZmlndXJhdGlvbiwgdGhlIHJlc3Qgc3RheXMg dGhlIHNhbWUgYXMgUkZDNjc1MC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+U3RhbmRhcmQgaW50ZXJmYWNlOiB0aGlzIGtpbmQgb2YgbWV0YWRhdGEgaXMgYXBwbGlj YWJsZSBub3Qgb25seSBmb3IgbGV0dGluZyB0aGUgY2xpZW50IGZpbmQgdGhlIGFwcHJvcHJpYXRl IGF1dGhvcml6YXRpb24gc2VydmVyIGJ1dCBmb3INCiBvdGhlciBtZXRhZGF0YSBhcyB3ZWxsLiBB bHNvLCBvdGhlciBlbmRwb2ludHMgYXMgbG9uZyBhcyBpdCBpcyBzdXBwb3J0aW5nIHRoZSBkaXJl Y3QgY29tbXVuaWNhdGlvbiB3aXRoIHRoZSBjbGllbnQsIGNhbiBwcm92aWRlIHJlbGV2YW50IG1l dGFkYXRhIHdpdGggaXQgd2l0aG91dCBnb2luZyB0aHJvdWdoIHRoZSBjbGllbnQgYXV0aG9yaXph dGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SSBkaWQgbm90 IHF1aXRlIGZvbGxvdyB3aHkgQ09SUyBpcyByZWxldmFudCBoZXJlLiBXZSBhcmUganVzdCB0YWxr aW5nIGFib3V0IHRoZSBjbGllbnQgdG8gc2VydmVyIGNvbW11bmljYXRpb24sIGFuZCB0aGVyZSBh cmUgbm8gZW1iZWRkZWQgcmVzb3VyY2VzIGluIHRoZSByZXNwb25zZS4gQ291bGQgeW91IGtpbmRs eSBlbGFib3JhdGUNCiBhIGxpdHRsZSwgcGxlYXNlPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPkZvciB0aGUgc2Vjb25kIHBvaW50LCBzaW5jZSBpdCB3YXMgZGlzY3Vzc2VkIGlu IHRoZSBXRyBtZWV0aW5nIHllc3RlcmRheSwgSSB3aWxsIGRlZmVyIHRvIHRoYXQgZGlzY3Vzc2lv bi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QmVzdCwgPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5OYXQgU2FraW11cmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gT0F1 dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5E YXZpZCBXYWl0ZTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxOSwgMjAxOCA0OjU1 IFBNPGJyPg0KPGI+VG86PC9iPiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbT0FVVEgtV0ddIHVwZGF0ZWQgRGlzdHJpYnV0ZWQgT0F1dGggSUQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvdXIgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaXJzdDogV2hhdCBpcyB0aGUgcmF0aW9uYWxl IGZvciBpbmNsdWRpbmcgdGhlIHBhcmFtZXRlcnMgYXMgTGluayBoZWFkZXJzIHJhdGhlciB0aGFu IHBhcnQgb2YgdGhlIFdXVy1BdXRoZW50aWNhdGUgY2hhbGxlbmdlLCBlLmcuOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V1dXLUF1dGhlbnRpY2F0ZTogQmVh cmVyIHJlYWxtPSZxdW90O2V4YW1wbGVfcmVhbG0mcXVvdDssPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Njb3BlPSZxdW90O2V4YW1wbGVfc2NvcGUmcXVvdDssPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Vycm9yPeKAnGludmFsaWRf dG9rZW4mcXVvdDssPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7IHJlc291cmNlX3VyaT0mcXVvdDs8YSBocmVmPSJodHRwczov L2FwaS5leGFtcGxlLmNvbS9yZXNvdXJjZSI+aHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20vcmVzb3Vy Y2U8L2E+JnF1b3Q7LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBvYXV0aF9zZXJ2ZXJfbWV0YWRhdGFfdXJpcz0mcXVvdDs8 YSBocmVmPSJodHRwczovL2FzLmV4YW1wbGUuY29tLy53ZWxsLWtub3duL29hdXRoLWF1dGhvcml6 YXRpb24tc2VydmVyIj5odHRwczovL2FzLmV4YW1wbGUuY29tLy53ZWxsLWtub3duL29hdXRoLWF1 dGhvcml6YXRpb24tc2VydmVyPC9hPg0KPGEgaHJlZj0iaHR0cHM6Ly9kaWZmZXJlbnQtYXMuZXhh bXBsZS5jb20vLndlbGwta25vd24vb2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2ZXIiPg0KaHR0cHM6 Ly9kaWZmZXJlbnQtYXMuZXhhbXBsZS5jb20vLndlbGwta25vd24vb2F1dGgtYXV0aG9yaXphdGlv bi1zZXJ2ZXI8L2E+JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB1bmRlcnN0YW5kaW5nIGlz IHRoYXQgdGhlIFJGQzY3NTAgYXV0aC1wYXJhbXMgYXJlIGV4dGVuc2libGUgKGJ1dCBub3QgY3Vy cmVudGx5IHBhcnQgb2YgYW55IG1hbmFnZWQgcmVnaXN0cnkuKTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIHJlYXNvbiB0byBn byB3aXRoIHRoaXMgdnMgTGluayBoZWFkZXJzIGlzIENPUlMgcG9saWN5IC0gZXhwb3NpbmcgTGlu ayBoZWFkZXJzIHRvIGEgcmVtb3RlIGNsaWVudCBtdXN0IGJlIGRvbmUgYWxsIG9yIG5vdGhpbmcg YXMgcGFydCBvZiB0aGUgQ09SUyBwb2xpY3ksIGFuZCBjYW7igJl0IGJlIGxpbWl0ZWQgYnkgdGhl IGtpbmQgb2YgbGluay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2Vjb25kOiAocmV0YWluaW5nIGxpbmsgZm9ybWF0KSBJcyB0aGVyZSBhIHJl YXNvbiB0aGUgbWV0YWRhdGEgbG9jYXRpb24gaXMgc3BlY2lmaWVkIHRoZSB3YXkgaXQgaXM/IEl0 IHNlZW1zIGxpa2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmx0OzxhIGhyZWY9Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20vLndlbGwta25vd24v b2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2ZXIiPmh0dHBzOi8vYXMuZXhhbXBsZS5jb20vLndlbGwt a25vd24vb2F1dGgtYXV0aG9yaXphdGlvbi1zZXJ2ZXI8L2E+Jmd0OzsgcmVsPeKAnG9hdXRoX3Nl cnZlcl9tZXRhZGF0YV91cmkmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+c2hvdWxkIGJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7PGEgaHJlZj0iaHR0cHM6Ly9h cy5leGFtcGxlLmNvbSI+aHR0cHM6Ly9hcy5leGFtcGxlLmNvbTwvYT4mZ3Q7OyByZWw94oCcb2F1 dGhfaXNzdWVyJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T0F1dGggZGVmaW5lcyB0aGUgbG9jYXRpb24gb2YgbWV0YWRh dGEgdW5kZXIgdGhlIC53ZWxsLWtub3duIGVuZHBvaW50IGFzIGEgTVVTVC4gQW4gZXh0ZW5zaW9u IG9mIE9BdXRoIG1heSBjaG9vc2UgZnJvbSBhdCBsZWFzdCB0aHJlZSBkaWZmZXJlbnQgbWV0aG9k cyBmb3IgaGFuZGxpbmcgZXh0ZW5zaW9ucyBiZXlvbmQgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIEFkZCBhZGRpdGlvbmFsIGtleXMg dG8gdGhlIG9hdXRoLWF1dGhvcml6YXRpb24tc2VydmVyIG1ldGFkYXRhPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBBZGQgYWRkaXRpb25hbCBy ZXNvdXJjZXMgdG8gLndlbGwta25vd24gZm9yIGNsaWVudHMgdG8gc3VwcG9ydGluZyB0aGVpciBl eHRlbnNpb25zIHRvIGF0dGVtcHQgdG8gcmVzb2x2ZSwgdHJlYXRpbmcg4oCYcmVndWxhcuKAmSBP QXV0aCBhcyBhIGZhbGxiYWNrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+My4gRGVmaW5lIHRoZWlyIG93biBwYXJhbWV0ZXIsIHN1Y2ggYXMgcmVs PeKAnHNwZWNpYWxhdXRoX2lzc3VlcuKAnSwgcG90ZW50aWFsbHkgdXNpbmcgYSBkaWZmZXJlbnQg bWVjaGFuaXNtIGZvciBzcGVjaWZ5aW5nIG1ldGFkYXRhPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVuIGFsbCB0aGlzLCBpdCBzZWVtcyBh cHByb3ByaWF0ZSB0byBvbmx5IHN1cHBvcnQgc3BlY2lmeWluZyBvZiBtZXRhZGF0YS1zdXBwbHlp bmcgaXNzdWVycywgbm90IG1ldGFkYXRhIHVyaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXJkOiBJIGhhdmUgZG91YnRzIG9mIHRoZSB1 c2VmdWxuZXNzIG9mIHJlc291cmNlX3VyaSBpbiBwYXJhbGxlbCB0byBib3RoIHRoZSBjbGllbnQg cmVxdWVzdGVkIFVSSSBhbmQgdGhlIEF1dGhvcml6YXRpb24g4oCccmVhbG3igJ0gcGFyYW1ldGVy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFzIGN1cnJlbnRseSBkZWZpbmVkLCB0aGUgY2xpZW50IHdvdWxkIGJlIHRoZSBvbmUg ZW5mb3JjaW5nIChvciBwb3NzaWJseSBpZ25vcmluZykgc3RhdGljIHBvbGljeSBhcm91bmQgcmVz b3VyY2UgVVJJcyAtIHRoYXQgYSByZXNvdXJjZSBVUkkgaXMgYXJiaXRyYXJ5IGV4Y2VwdCBpbiB0 aGF0IGl0IG11c3QgbWF0Y2ggdGhlIGhvc3QgKGFuZCBzY2hlbWUvcG9ydD8pIG9mIHRoZSByZXF1 ZXN0ZWQgVVJJLiBUaGUNCiBpbmZvcm1hdGlvbiBvbiB0aGUgcmVxdWVzdGVkIFVSSSBieSB0aGUg Y2xpZW50IGlzIG5vdCBzaGFyZWQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCBBUyBmb3IgaXQgdG8g ZG8gaXRzIG93biBwb2xpY3kgdmVyaWZpY2F0aW9uLiBJdCB3b3VsZCBzZWVtIGJldHRlciB0byBz ZW5kIHRoZSBjbGllbnQgb3JpZ2luIHRvIHRoZSBBUyBmb3IgaXQgdG8gZG8gKHBvdGVudGlhbCkg cG9saWN5IHZlcmlmaWNhdGlvbiwgcmF0aGVyIHRoYW4gcmVseWluZyBvbiBjbGllbnRzDQogdG8g aW1wbGVtZW50IGl0IGZvciB0aGVtIGJhc2VkIG9uIHN0YXRpYyBzcGVjIHBvbGljeS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG5hbWUg 4oCccmVzb3VyY2UgVVJJ4oCdIGlzIGFsc28gY29uZnVzaW5nLCBhcyBJIHdvdWxkIGV4cGVjdCBp dCB0byBiZSB0aGUgVVJJIHRoYXQgd2FzIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LiBUaGUgcHVy cG9zZSBvZiB0aGlzIHBhcmFtZXRlciBpcyBhIGJpdCBjb25mdXNpbmcsIGFzIGl0IGlzIG9ubHkg ZGVmaW5lZCBhcyDigJxBbiBPQXV0aCAyLjAgUmVzb3VyY2UgRW5kcG9pbnQgc3BlY2lmaWVkIGlu IFtSRkM2NzUwXQ0KIHNlY3Rpb24gMy4yIC0gd2hlcmUgdGhlIHRlcm0gZG9lc27igJl0IGFwcGVh ciBpbiA2NzUwIGFuZCB0aGVyZSBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgYSBzZWN0aW9uIDMuMiA7 LSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SXQgc2VlbXMgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmEuIElmIHRoZSByZXNvdXJjZV91cmkgaXMgYSBkaXJlY3QgbWF0Y2ggZm9yIHRo ZSBVUkkgcmVxdWVzdGVkIGZvciB0aGUgY2xpZW50LCBpdCBpcyByZWR1bmRhbnQgYW5kIHNob3Vs ZCBiZSBkcm9wcGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7IChJZiB0aGUgcmVzb3VyY2UgVVJJIGlzICpub3QqIGEgZGly ZWN0IG1hdGNoIHdpdGggdGhlIFVSSSBvZiB0aGUgcmVzb3VyY2UgcmVxdWVzdGVkIGJ5IHRoZSBj bGllbnQsIGl0IG1pZ2h0IG5lZWQgYSBiZXR0ZXIgbmFtZSkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iLiBJZiB0aGUgcmVzb3VyY2UgVVJJIGlz IG1lYW50IHRvIHByb3ZpZGUgYSBjZXJ0YWluIGFyYml0cmFyeSBncm91cGluZyBmb3IgYXBwbHlp bmcgdG9rZW5zIHdpdGhpbiB0aGUgb3JpZ2luIG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIsIHdoYXQg aXMgaXRzIHZhbHVlIG92ZXIgdGhlIHByZWV4aXN0aW5nIOKAnCZuYnNwO3JlYWxt4oCdIHBhcmFt ZXRlcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmMuIElmIHRoZSByZXNvdXJjZSBVUkkgaXMgbWVhbnQgdG8gcHJvdmlkZSBhIHdheSBmb3IgYW4g QVMgdG8gYWxsb3cgcmVzb3VyY2VzIHRvIGJlIGluZGVwZW5kZW50LCBpZGVudGlmaWVkIGVudGl0 aWVzIG9uIGEgc2luZ2xlIG9yaWdpbiAtIEnigJltIHVuc3VyZSBob3cgYSBjbGllbnQgd291bGQg dW5kZXJzdGFuZCBpdCBpcyBtZWFudCB0byB0cmVhdCB0aGVzZSByZXNvdXJjZSBVUklzIGFzIGlu ZGVwZW5kZW50IGVudGl0aWVzDQogKGUuZy4gYmUgc3VyZSBub3QgdG8gc2VuZCBiZWFyZXIgdG9r ZW5zIG1pbnRlZCBmb3IgcmVzb3VyY2UgL2VudGl0eTEgdG8gL2VudGl0eTIsIG9yIGZvciB0aGF0 IG1hdHRlciBwcmV2ZW50IC9lbnRpdHkxIGZyb20gcmVxdWVzdGluZyB0b2tlbnMgZm9yIC9lbnRp dHkyKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFkbWl0dGVkbHkgYmFzZWQgb24gbm90IGZ1bGx5IHVuZGVyc3RhbmRpbmcgdGhl IHB1cnBvc2Ugb2YgdGhpcyBwYXJhbWV0ZXIsIGl0IHNlZW1zIHRvIG1lIHRoZXJlIGV4aXN0cyBh IHNpbXBsZXIgZmxvdyB3aGljaCBiZXR0ZXIgbGV2ZXJhZ2VzIHRoZSBleGlzdGluZyBBdXRoZW50 aWNhdGlvbiBtZWNoYW5pc20gb2YgSFRUUC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSByZXF1ZXN0IHdvdWxkIGZhaWwgZHVlIHRv IGFuIGludmFsaWQgb3IgbWlzc2luZyB0b2tlbiBmb3IgdGhlIHJlYWxtIGF0IHRoZSBvcmlnaW4s IGFuZCBhbmQgdGhlIGNsaWVudCB3b3VsZCBtYWtlIGEgcmVxdWVzdCB0byB0aGUgaXNzdWVyIGlu Y2x1ZGluZyB0aGUgb3JpZ2luIG9mIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2UgYXMgYSBwYXJhbWV0 ZXIuIEFueSBvdGhlciBpbmNsdWRlZCBwYXJhbWV0ZXJzIHNwZWNpZmllZA0KIGJ5IHRoZSBXV1ct QXV0aGVudGljYXRlIGNoYWxsZW5nZSB1bmRlcnN0b29kIGJ5IHRoZSBjbGllbnQmbmJzcDsoc3Vj aCBhcyDigJxzY29wZeKAnSkgd291bGQgYWxzbyBiZSBhcHBsaWVkIHRvIHRoaXMgcmVxdWVzdC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm9y bWFsIGF1dGhvcml6YXRpb24gZ3JhbnQgZmxvdyB3b3VsZCB0aGVuIGhhcHBlbiAoYXMgdGhpcyBp cyB0aGUgb25seSBncmFudCB0eXBlIHN1cHBvcnRlZCBieSBSRkM2NzUwKS4gT25jZSB0aGUgYWNj ZXNzIHRva2VuIGlzIGFjcXVpcmVkIGJ5IHRoZSBjbGllbnQsIHRoZSBjbGllbnQgYXNzb2NpYXRl cyB0aGF0IHRva2VuIHdpdGggdGhlIOKAnHJlYWxt4oCdIHBhcmFtZXRlciBnaXZlbiBpbiB0aGUg aW5pdGlhbCBjaGFsbGVuZ2UNCiBieSB0aGUgcmVzb3VyY2Ugc2VydmVyIG9yaWdpbi4gTGlrZXdp c2UsIHRoZSDigJhhdWTigJkgb2YgdGhlIHRva2VuIGFzIHJldHVybmVkIGJ5IGEgdG9rZW4gaW50 cm9zcGVjdGlvbiBwcm9jZXNzIHdvdWxkIGJlIHRoZSBvcmlnaW4gb2YgdGhlIHJlc291cmNlIHNl cnZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SXQgc2VlbXMgYW55IG1vcmUgY29tcGxpY2F0ZWQgcHJvdGVjdGVkIHJlc291cmNlIGdyb3Vw aW5ncyBvbiBhIHJlc291cmNlIHNlcnZlciB3b3VsZCBuZWVkIGEgY2xpZW50IHRvIHVuZGVyc3Rh bmQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgcmVzb3VyY2Ugc2VydmVyLCBhbmQgdGh1cyBmZXRjaCBz b21lIHNvcnQgb2YgcmVzb3VyY2Ugc2VydmVyIG1ldGFkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3VydGggYW5kIGZpbmFsbHk6IElz IHRoZSBpbnRlbnRpb24gdG8gZXZlbnR1YWxseSByZWNvbW1lbmQgdG9rZW4gYmluZGluZyBoZXJl PyBUb2tlbiBiaW5kaW5nIGFzIGEgcmVxdWlyZW1lbnQgYWNyb3NzIGNsaWVudHMsIHJlc291cmNl cywgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcnMgd291bGQgaXNvbGF0ZSB0b2tlbnMgdG8g b25seSBiZWluZyBjb25zdW1lZCB3aXRoaW4gYW4gb3JpZ2luLiBUaGlzDQogd291bGQgYWN0dWFs bHkgbWFrZSByZWR1bmRhbnQvc3VwcGxlbWVudGFsIHRoZSBBUyBhZGRpdGlvbnMgZGVmaW5lZCB3 aXRoaW4gdGhpcyBzcGVjIChyZXNvdXJjZS9vcmlnaW4gcmVxdWVzdCBwYXJhbWV0ZXIsIOKAmGF1 ZOKAmSBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlIG1lbWJlcik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LURXPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1biAxMiwgMjAxOCwgYXQgMToy OCBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29t Ij5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGV5IE9BdXRoIFdHPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgd29ya2VkIHdpdGggTmF0IGFuZCBC cmlhbiB0byBtZXJnZSBvdXIgY29uY2VwdHMgYW5kIHRob3NlIGFyZSBjYXB0dXJlZCBpbiB0aGUg dXBkYXRlZCBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaGFyZHQtb2F1dGgtZGlzdHJpYnV0ZWQvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1oYXJkdC1vYXV0aC1kaXN0cmlidXRlZC88L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBob3BlZnVsIHRoZSBX RyB3aWxsIGFkb3B0IHRoaXMgZHJhZnQgYXMgYSBXRyBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55IGNvbW1lbnRzIGFuZCBm ZWVkYmFjayBhcmUgd2VsY29tZSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+L0RpY2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_TY2PR01MB2297DBA5677C67441221DF54F9510TY2PR01MB2297jpnp_-- From nobody Fri Jul 20 07:07:00 2018 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 1F987130DE7 for ; Fri, 20 Jul 2018 07:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 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, T_DKIMWL_WL_HIGH=-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=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 poqQlsqv6hGT for ; Fri, 20 Jul 2018 07:06:55 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on0115.outbound.protection.outlook.com [104.47.53.115]) (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 B5742130DD8 for ; Fri, 20 Jul 2018 07:06:54 -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=jGCoqVNhhhE83hzFFhhfap3uFwTBV/zukBuI/Oh/oT0=; b=eriRoQzC55SuJAvkpJy0XeoaiJ9PaU6aVOlrS6eHvn1yPiuktTCmUe++Yr9R4gRc0bbErwAP0TZM+BEHMrFzF2znybh61X3FNlFTBTe8q0qkCHnO7EPb852/NF5onf0SBt+3sKAn8KCAUZjouk2/iKcgSXur4pctkHeFCzvHOnw= Received: from DM5PR00MB0389.namprd00.prod.outlook.com (52.132.129.25) by DM5PR00MB0358.namprd00.prod.outlook.com (52.132.128.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1014.0; Fri, 20 Jul 2018 14:06:52 +0000 Received: from DM5PR00MB0389.namprd00.prod.outlook.com ([fe80::5d46:7952:6aa0:e10a]) by DM5PR00MB0389.namprd00.prod.outlook.com ([fe80::5d46:7952:6aa0:e10a%3]) with mapi id 15.20.1019.000; Fri, 20 Jul 2018 14:06:52 +0000 From: Anthony Nadalin To: Rifaat Shekh-Yusef , oauth Thread-Topic: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" Thread-Index: AQHUH4gZ4YlaG/gRw0eQMEg8QI9R2aSYJicA Date: Fri, 20 Jul 2018 14:06:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.149.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0358; 6:lOjv2fESWcj+PW1N9wEO+bHNwoaKZ+juKWjTlfH9LB5mEi+xF+Fa/6Twl4IhHiNqS+zXBjFOGAgOa548wdsNBQfGgimM6CdVrjoRiu9UqnwLm/+Vc1prOZWBSqZ08M0GQrjgxeqj0Wr479A1xUMn/G/mbmk7UN3F11Gt+fRF+ytJtF3zyFe/PDQcX1MJ++yZXC7c3vfAQlpThg6pNRmF3UMWOMfaNgkrdii+1TKkbXWBms8D9aZCSXezyn4tk+UJ5Oxg4Oa8dm65GEnw2hKlOBYrrNpaKIBntNqa/QJRIuYXURagTTjyDScCJ4pcrYslRC4ICYYXkJkIdu0wKLzxNq02eYYXeQUOSj5d1TJPwDh4E+5otRlysd5JbQuoxb5FUnAmI8+t2ZoiB4b79+uPknRjPLXvggmqeOOdWDYiCKdGdpCsX9M5VgorR6sttEdP9zUsHMDgol9pgdLwv9SlFQ==; 5:4Q3JssTJuEA0FH3hOvtPPoRQHWcpqyHKiPMc40vV2hgezwbSgyTxgy9g2g2LBAHBBmOqx7rq9NBLGQ7QsaFESEREjdfoWzqRsAH6FfcF4c+ZvzeOsQdVRxhZQ9pRkscBaJr/oU7JcrCGVvTUaocsrVy40WOxlbSaILjYllcxTCU=; 7:t/H1lWXisjEWMVviasRGyHckMNOP1VuJ5KW+u0A3GyyMOFnOCTaXGS2/utJi5oDBbcbQtgZRJcrrqN1caDZ2FccSlcrYHeTy0JhSPo8e78RlvJ3sTJl/288doO2Zj7XvaGanklcYTQPpDIW9YZz/AKwkri+t+XNDXPZHl9mnsp8mfh7xZ9BbmywnRlsZFaVyzC9UB2b2orPawQhcraIK5sPvoNv4+XfRLxGmw+9JegfW8Lzl/hoSGdDPgeaT2Xi5 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f132ec62-a069-42ce-edb5-08d5ee4a0b33 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:DM5PR00MB0358; x-ms-traffictypediagnostic: DM5PR00MB0358: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(192374486261705)(189930954265078)(219752817060721)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(2018427008)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DM5PR00MB0358; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0358; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(396003)(136003)(39860400002)(53754006)(189003)(199004)(9686003)(6306002)(229853002)(486006)(66066001)(478600001)(110136005)(14454004)(966005)(316002)(476003)(606006)(81156014)(8676002)(33656002)(99286004)(10290500003)(22452003)(81166006)(8936002)(2906002)(76176011)(10090500001)(11346002)(8990500004)(14444005)(54896002)(256004)(25786009)(2900100001)(86362001)(26005)(186003)(6246003)(7696005)(68736007)(53546011)(6506007)(790700001)(236005)(6436002)(55016002)(6116002)(19609705001)(3846002)(39060400002)(106356001)(446003)(105586002)(7736002)(86612001)(97736004)(5660300001)(5250100002)(74316002)(102836004)(53936002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0358; H:DM5PR00MB0389.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) x-microsoft-antispam-message-info: azChls5IthFeTr34yjDo97KJyKtHww3WXPdWauHxJCrfGsjlj2Q6Lzq/mKuf+GOQrapvDlQgLl9EmUoF1iO0fSbT/rIBEuBJtVX/UDjazMq2YsyHh6ipDB8J93sG8FWqEODm4XF870dMxFiKLC70lnxqQJiiyntLYLvctiGG8TpFR/E0eXU0vujSuckyHZwB0IzwL7w/rnb6Q0ka4vCc6nPoLlRE3mHPptrqACS9N2EkT3wTt5IR7wndFAdovnRn1CdVPn1LyeOYQmErSRMr+vUe+/2fxEuPVpiN5iirj3ehaxuHMLmfIibvWxkWBb3YlWv+W5iI33VTseWm4A3S3cnb3EIM0yuEIAExBoK0KQM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB03898165B0E24AA4A41610E9A6510DM5PR00MB0389namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f132ec62-a069-42ce-edb5-08d5ee4a0b33 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 14:06:52.4215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0358 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 14:06:58 -0000 --_000_DM5PR00MB03898165B0E24AA4A41610E9A6510DM5PR00MB0389namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gY29uY2VybmVkIG92ZXIgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiBhIGNsaWVu dCBiZWluZyBhYmxlIHRvIGludHJvc3BlY3QgYSB0b2tlbiwgZm9yIGJlYXJlciB0b2tlbnMgdGhp cyBjYW4gYmUgdmVyeSBwcm9ibGVtYXRpYywgc28gdW5sZXNzIHRoZSBpc3N1ZXMgd2l0aCBwb3Nz aWJsZSB0b2tlbiB0aGVmdCBjYW4gYmUgYWRkcmVzc2VkIEkgZG9u4oCZdCBzdXBwb3J0IHRoaXMg YXMgYSBXRyBkcmFmdA0KDQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIFJpZmFhdCBTaGVraC1ZdXNlZg0KU2VudDogVGh1cnNkYXksIEp1bHkgMTksIDIw MTggMTA6NDQgQU0NClRvOiBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgt V0ddIENhbGwgZm9yIGFkb3B0aW9uIG9mICJKV1QgUmVzcG9uc2UgZm9yIE9BdXRoIFRva2VuIElu dHJvc3BlY3Rpb24iDQoNCkhpIGFsbCwNCg0KVGhpcyBpcyB0aGUgY2FsbCBmb3IgYWRvcHRpb24g b2YgdGhlICdKV1QgUmVzcG9uc2UgZm9yIE9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24nIGRvY3Vt ZW50IGZvbGxvd2luZyB0aGUgcHJlc2VudGF0aW9uIGJ5IFRvcnN0ZW4gYXQgdGhlIE1vbnRyZWFs IElFVEYgbWVldGluZyB3aGVyZSB3ZSBkaWRuJ3QgaGF2ZSBhIGNoYW5jZSB0byBkbyBhIGNhbGwg Zm9yIGFkb3B0aW9uIGluIHRoZSBtZWV0aW5nIGl0c2VsZi4NCg0KSGVyZSBpcyBwcmVzZW50YXRp b24gYnkgVG9yc3RlbjoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDIv bWF0ZXJpYWxzL3NsaWRlcy0xMDItb2F1dGgtc2Vzc2Etand0LXJlc3BvbnNlLWZvci1vYXV0aC10 b2tlbi1pbnRyb3NwZWN0aW9uLTAwPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZtZWV0 aW5nJTJGMTAyJTJGbWF0ZXJpYWxzJTJGc2xpZGVzLTEwMi1vYXV0aC1zZXNzYS1qd3QtcmVzcG9u c2UtZm9yLW9hdXRoLXRva2VuLWludHJvc3BlY3Rpb24tMDAmZGF0YT0wMiU3QzAxJTdDdG9ueW5h ZCU0MG1pY3Jvc29mdC5jb20lN0M1YmI0ZDEyNjE4OTQ0Y2M4ZGE0YjA4ZDVlZDlmMzg2YiU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2NzYxOTA0NzgwNzkz Njgmc2RhdGE9d3Y4ZSUyRnZHRG05THplSmFHck9CRDhvR1hnUFNxdU5FJTJCUktpRWtuRjhzcTQl M0QmcmVzZXJ2ZWQ9MD4NCg0KSGVyZSBpcyB0aGUgZG9jdW1lbnQ6DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVz cG9uc2UtMDE8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1sb2RkZXJzdGVk dC1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMSZkYXRhPTAyJTdDMDElN0N0b255 bmFkJTQwbWljcm9zb2Z0LmNvbSU3QzViYjRkMTI2MTg5NDRjYzhkYTRiMDhkNWVkOWYzODZiJTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY3NjE5MDQ3ODA3 OTM2OCZzZGF0YT1jRklTT1ZtYThnJTJCWGR2ZjJLWmR3Q1pCWWxwZk4lMkZHYjJrbnY4WkQ5c0t6 NCUzRCZyZXNlcnZlZD0wPg0KDQpQbGVhc2UgbGV0IHVzIGtub3cgYnkgQXVndXN0IDJuZCB3aGV0 aGVyIHlvdSBhY2NlcHQgLyBvYmplY3QgdG8gdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQg YXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBpbiB0aGUgT0F1dGggd29ya2luZyBncm91cC4N Cg0KUmVnYXJkcywNCkhhbm5lcyAmIFJpZmFhdA0K --_000_DM5PR00MB03898165B0E24AA4A41610E9A6510DM5PR00MB0389namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J 4oCZbSBjb25jZXJuZWQgb3ZlciB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIGEgY2xpZW50 IGJlaW5nIGFibGUgdG8gaW50cm9zcGVjdCBhIHRva2VuLCBmb3IgYmVhcmVyIHRva2VucyB0aGlz IGNhbiBiZSB2ZXJ5IHByb2JsZW1hdGljLCBzbyB1bmxlc3MgdGhlIGlzc3VlcyB3aXRoIHBvc3Np YmxlIHRva2VuIHRoZWZ0IGNhbiBiZSBhZGRyZXNzZWQgSSBkb27igJl0IHN1cHBvcnQgdGhpcyBh cyBhIFdHIGRyYWZ0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBPQXV0aCAm bHQ7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NClJpZmFh dCBTaGVraC1ZdXNlZjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxOSwgMjAxOCAx MDo0NCBBTTxicj4NCjxiPlRvOjwvYj4gb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIENhbGwgZm9yIGFkb3B0aW9uIG9mICZxdW90O0pX VCBSZXNwb25zZSBmb3IgT0F1dGggVG9rZW4gSW50cm9zcGVjdGlvbiZxdW90OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyB0aGUgY2FsbCBmb3IgYWRv cHRpb24gb2YgdGhlICdKV1QgUmVzcG9uc2UgZm9yIE9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24n IGRvY3VtZW50IGZvbGxvd2luZyB0aGUgcHJlc2VudGF0aW9uIGJ5IFRvcnN0ZW4gYXQgdGhlIE1v bnRyZWFsIElFVEYgbWVldGluZyB3aGVyZSB3ZSBkaWRuJ3QgaGF2ZSBhIGNoYW5jZSB0byBkbyBh IGNhbGwgZm9yIGFkb3B0aW9uIGluIHRoZSBtZWV0aW5nIGl0c2VsZi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBpcyBwcmVzZW50YXRp b24gYnkgVG9yc3Rlbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZtZWV0aW5n JTJGMTAyJTJGbWF0ZXJpYWxzJTJGc2xpZGVzLTEwMi1vYXV0aC1zZXNzYS1qd3QtcmVzcG9uc2Ut Zm9yLW9hdXRoLXRva2VuLWludHJvc3BlY3Rpb24tMDAmYW1wO2RhdGE9MDIlN0MwMSU3Q3Rvbnlu YWQlNDBtaWNyb3NvZnQuY29tJTdDNWJiNGQxMjYxODk0NGNjOGRhNGIwOGQ1ZWQ5ZjM4NmIlN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Njc2MTkwNDc4MDc5 MzY4JmFtcDtzZGF0YT13djhlJTJGdkdEbTlMemVKYUdyT0JEOG9HWGdQU3F1TkUlMkJSS2lFa25G OHNxNCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0 aW5nLzEwMi9tYXRlcmlhbHMvc2xpZGVzLTEwMi1vYXV0aC1zZXNzYS1qd3QtcmVzcG9uc2UtZm9y LW9hdXRoLXRva2VuLWludHJvc3BlY3Rpb24tMDA8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgdGhlIGRvY3VtZW50OjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0i aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1q d3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMSZhbXA7ZGF0YT0wMiU3QzAxJTdDdG9ueW5hZCU0 MG1pY3Jvc29mdC5jb20lN0M1YmI0ZDEyNjE4OTQ0Y2M4ZGE0YjA4ZDVlZDlmMzg2YiU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2NzYxOTA0NzgwNzkzNjgm YW1wO3NkYXRhPWNGSVNPVm1hOGclMkJYZHZmMktaZHdDWkJZbHBmTiUyRkdiMmtudjhaRDlzS3o0 JTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbG9k ZGVyc3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDE8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBsZXQg dXMga25vdyBieSBBdWd1c3QgMm5kIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGUg YWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGlu IHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFubmVzICZhbXA7IFJpZmFhdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR00MB03898165B0E24AA4A41610E9A6510DM5PR00MB0389namp_-- From nobody Fri Jul 20 07:14:28 2018 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 19723130DCE for ; Fri, 20 Jul 2018 07:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=ve7jtb-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 H4iOIRv4FUeG for ; Fri, 20 Jul 2018 07:14:22 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 123FA129619 for ; Fri, 20 Jul 2018 07:14:21 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id h2-v6so14896393itj.1 for ; Fri, 20 Jul 2018 07:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=fc+jV0ld7lC193Zz4R5whh2iRf3S7ksGHUVZzt99yyE=; b=t5JQ31M03OndgcVTXyAcmYSWWuISltGBUI18OidhAO00t263rRLYNptc0P+Ll96qaP G7ljMQhWft/nBuJzFJ0q0UoNlMcNd5Nk94uoS0qWvpKFNypVfcJZW4/u5kjnlm/5zRQw JZjuIdtKpnDUPDstLp6h5O4xz5j3BGQ1xVFH/UVTouGlaiYL2InYNjxKQshHJ0JIWQrN j6au+6m/29Ec+qvyR9kme0a3vY6Ww1PU5GoYIrBaTJxWMWie4xNTOt39033TAwMOG1Nq YHm0ivK5t90OqM+Bs9nLR75uugLFDPHYOr1IP+0fZw5KHd5j9LCgaEgPf0ZPxd5R6rCl 7DIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=fc+jV0ld7lC193Zz4R5whh2iRf3S7ksGHUVZzt99yyE=; b=A+NOuzL+kFR3BakOrr/3BnLnADArQ41kmVcXu2y0nYicGvr811F9+DuFldwV9NZJMi E2LXFw7HKBtdvUMuUd3E6+viMAecx7hREcJl4FIa5Vdo5ayE9aZQ1UyBYljB9pD/W1Ej cgweI8mYRMviD4HdvBURh2CGv81JwsvhxIHLkCmPFlbRX4anxZa/bqDBAC6hKncnSdqg xajFLmq9CbVrC9YECNIw9gN9ypAs99Qj/PMhwpdXP5z4SPRFSw8lCSXBx4HnHdhyF1HS R+QEuECQjlMrt/fDIYrUupSp3BTYubFDqeU9pCezOnhKguHpOdZZJV78QM8W2gZggN6W 8K5g== X-Gm-Message-State: AOUpUlF8Kgli3cam32rn/rkWLwcIeaQEWtWkZFmz3iCUCkx85dq2WBxh vfQVIlSLeY+7m41smqK+LW4lwQ== X-Google-Smtp-Source: AAOMgpfhmDS4h963NFH9RKTuiX7BNBEcmYlwQBZwwVyRMA66NNv/tN7/VQPgEpbwElz8mMIV6Jv+TA== X-Received: by 2002:a02:ab97:: with SMTP id t23-v6mr1944515jan.17.1532096060969; Fri, 20 Jul 2018 07:14:20 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:bc3a:605c:eed5:5b4d? ([2001:67c:370:128:bc3a:605c:eed5:5b4d]) by smtp.gmail.com with ESMTPSA id 186-v6sm774854ioo.17.2018.07.20.07.14.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jul 2018 07:14:19 -0700 (PDT) Message-ID: <5b51ee3b.1c69fb81.b1ede.474b@mx.google.com> MIME-Version: 1.0 To: Rifaat Shekh-Yusef , oauth From: John Bradley Date: Fri, 20 Jul 2018 10:14:17 -0400 Importance: normal X-Priority: 3 In-Reply-To: References: Content-Type: multipart/alternative; boundary="_470CE9AF-51FB-4D33-8F3E-7F91A6B7C6F6_" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth TokenIntrospection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 14:14:24 -0000 --_470CE9AF-51FB-4D33-8F3E-7F91A6B7C6F6_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I am in favor of adoption. Sent from Mail for Windows 10 From: Rifaat Shekh-Yusef Sent: Thursday, July 19, 2018 1:44 PM To: oauth Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth TokenIntro= spection" Hi all, This is the call for adoption of the 'JWT Response for OAuth Token Introspe= ction' document following the presentation by Torsten at the Montreal IETF = meeting where we didn't have a chance to do a call for adoption in the meet= ing itself. Here is presentation by Torsten: https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-j= wt-response-for-oauth-token-introspection-00 Here is the document: https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-respo= nse-01 Please let us know by August 2nd whether you accept / object to the adoptio= n of this document as a starting point for work in the OAuth working group. Regards, Hannes & Rifaat --_470CE9AF-51FB-4D33-8F3E-7F91A6B7C6F6_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I am in favor of adoption.

 

 <= /p>

Sent from Mail for Windows 10

&n= bsp;

From: Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 1:= 44 PM
To: oauth
Subje= ct: [OAUTH-WG] Call for adoption of "JWT Response for OAuth TokenI= ntrospection"

 

=

Hi all,

&= nbsp;

This is the call for adoptio= n of the 'JWT Response for OAuth Token Introspection' document following th= e presentation by Torsten at the Montreal IETF meeting where we didn't have= a chance to do a call for adoption in the meeting itself.

 

Her= e is presentation by Torsten:

 

Here is the document:

 

Please let us kn= ow by August 2nd whether you accept / object to the adoption of this docume= nt as a starting point for work in the OAuth working group.

<= p class=3DMsoNormal> 

Re= gards,

Hannes & Rifaat

 

= --_470CE9AF-51FB-4D33-8F3E-7F91A6B7C6F6_-- From nobody Fri Jul 20 07:16:33 2018 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 6E19C130E0F for ; Fri, 20 Jul 2018 07:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=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 6R3UIfFAjOa8 for ; Fri, 20 Jul 2018 07:16:16 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10084.outbound.protection.outlook.com [40.107.1.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5C31311C8 for ; Fri, 20 Jul 2018 07:16:03 -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=4j0Q1AZk92Nbvq+J/yxfVeXPOQTqAI49sBfS5tuyiJU=; b=T9QigJlq4uKGBGks02riQdhI/c50hVIrkokwub18yPof365vvVdo22oZJsaogwgDTmorksvHMaqEdxlTKXXG0JnwujZl0fzRwXRqDSqK6EPIRBNRmrS1j0pycAqs2Hof/N4rHdDHMO7FcKL+WpqVyjiJrXsgXrDIgQAyFZVxMoY= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1278.eurprd08.prod.outlook.com (10.167.197.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Fri, 20 Jul 2018 14:16:00 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Fri, 20 Jul 2018 14:16:00 +0000 From: Hannes Tschofenig To: Anthony Nadalin , Rifaat Shekh-Yusef , oauth Thread-Topic: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" Thread-Index: AQHUH4gXdJvYc5Qzg0SLBaEcvWfZcaSYJsAAgAACFGA= Date: Fri, 20 Jul 2018 14:15:59 +0000 Message-ID: References: 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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1278; 6:kxiTYJuRD2NHEOLBda8Ewivl4mWUiMzm/urkyMdS/k7/XDECziHs6t0hzwKuM1RO9FKjs4kRqDyPEL+HIJxMX1z7EhO4hl3/yEhcsWXxaJi1F00S+/h55iJ1usDNmLXxMV+wwzlL4yNBb5ryHm5v4HlCU64a9iLJO/0ifyGi02xiqa4ePXir0ZdQ7yt9lB7NRbWlQvBw9GxgJOTHfi0pIV5QIAslTxcd2kSmugARokIDlduWw1Lu1cefdTBlbuuBd6AOOMqx6Nsz5/+YF0HkiZlB6Z8kHMKw4YL67yTzGrDa57LYGtoPyhHXk12jCSuIzDlOhK+SDa2x+Cxp2ChrtlO+sIaOskBTG3GHTIGw0pi94NJ41kBkSFZQEnPVaxvR06ZNMWu8k7Ye4ojY66JDJxl0f35DARauOkkCuv4YAKRhHw6olq6cOIPE19HRYEN5qUIC+mkTmTu/z2lTnTacew==; 5:Gf74uPQHVOsLWZn6XmBJMtg5g5ubLWMby+DlwaaghJfqxaLDcokgST3DGoaQStrde0M/NYddWhtnw1EmHJ3YnMgJcLu08Dhfyu1LPQ7sTNouhGgd5uxuPWDvPga7eO+pf24aaPw7FEsMx70q9l0Bz8bUXY05SQNRxX3Uf1/GoNo=; 7:qnClT6E7ZwwXR2vaT5wVR5VW2cB2G1gqB9Svm413vEQ2e36R+FOYXmdMp0FS8Ez+7ZuL3Iu81ofUxLyImNnLNXXiJLyQRpLUto4H1+0WntphpRi5sSQreDBA++tRR5D0TzvBhphoPGIIZPNdGf/9fCqBKjeHgysr0QpZ3X5vMc9R+4Hz6J25SjogahT4h0YexALZ4jwQhNCobRG8k/l7e3k4BBmEom+k4zIvRu4kbSPmYf7BdKTMqvhXQxIKoGG1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6e203d82-f21d-4574-626f-08d5ee4b5189 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1278; x-ms-traffictypediagnostic: VI1PR0801MB1278: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(192374486261705)(189930954265078)(223705240517415)(219752817060721)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1278; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1278; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(396003)(376002)(346002)(53754006)(199004)(40434004)(189003)(86362001)(3846002)(6506007)(14444005)(11346002)(55016002)(76176011)(6436002)(446003)(5024004)(14454004)(54896002)(186003)(476003)(74316002)(7736002)(6116002)(966005)(9686003)(229853002)(6306002)(26005)(236005)(53546011)(256004)(102836004)(68736007)(72206003)(790700001)(81156014)(81166006)(606006)(5660300001)(97736004)(316002)(8936002)(478600001)(33656002)(6246003)(25786009)(99286004)(39060400002)(7696005)(2900100001)(486006)(2906002)(105586002)(66066001)(106356001)(110136005)(8676002)(53936002)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1278; 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-microsoft-antispam-message-info: Vbm0u2qDwF+mDeAxVgUnml1kd6X8aP4aYS2U+Q/+8HbO6yduBWduZamJdxAuIBFo4W0ixfQ3TZvbRND1uXBWLM1mFyMRrZ0szCiR9Vkybv0UpmlWusoW9tJWFynvCqyhmGkiUzlL9ndB2d/+ywLYXo94sYLSW9jyDCmElhtI135oZmFBP30fr1JsfU1OatiKYJ2u11IqwYwerX1uPlrSi3k8rtuFM5PgH48DpS2L65emG4RPQzca+/GpVDjWTnkz4wTG7514KkllYWrdybOrQG1wFrQ5TUA5iWbfWRjonWerBBFoNZDEQC97iN6pOwhtZwPnLLtHla92/oSqn0/b60qZCUE5OcFatg5Ak/A2qN4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112D9BE45C4F852CEAF0E4FFA510VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6e203d82-f21d-4574-626f-08d5ee4b5189 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 14:15:59.9227 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1278 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 14:16:31 -0000 --_000_VI1PR0801MB2112D9BE45C4F852CEAF0E4FFA510VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIGNvbXBhbmllcyBkb2luZyB0b2tlbiBpbnRyb3NwZWN0aW9uIGJ5IHRoZSBjbGll bnQgYWxyZWFkeSwgc2VlIGh0dHBzOi8vYmFja3N0YWdlLmZvcmdlcm9jay5jb20vZG9jcy9hbS82 L29hdXRoMi1ndWlkZS8jc2VjLXN0YW5kYXJkcw0KDQpXaGF0IHNlY3VyaXR5IGltcGxpY2F0aW9u cyBkbyB5b3Ugc2VlPw0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBBbnRob255IE5hZGFsaW4NClNlbnQ6IDIwIEp1bHkgMjAxOCAxMDow Nw0KVG86IFJpZmFhdCBTaGVraC1ZdXNlZjsgb2F1dGgNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IENhbGwgZm9yIGFkb3B0aW9uIG9mICJKV1QgUmVzcG9uc2UgZm9yIE9BdXRoIFRva2VuIEludHJv c3BlY3Rpb24iDQoNCknigJltIGNvbmNlcm5lZCBvdmVyIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlv bnMgb2YgYSBjbGllbnQgYmVpbmcgYWJsZSB0byBpbnRyb3NwZWN0IGEgdG9rZW4sIGZvciBiZWFy ZXIgdG9rZW5zIHRoaXMgY2FuIGJlIHZlcnkgcHJvYmxlbWF0aWMsIHNvIHVubGVzcyB0aGUgaXNz dWVzIHdpdGggcG9zc2libGUgdG9rZW4gdGhlZnQgY2FuIGJlIGFkZHJlc3NlZCBJIGRvbuKAmXQg c3VwcG9ydCB0aGlzIGFzIGEgV0cgZHJhZnQNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSaWZhYXQgU2hla2gtWXVzZWYNClNlbnQ6IFRodXJzZGF5 LCBKdWx5IDE5LCAyMDE4IDEwOjQ0IEFNDQpUbzogb2F1dGggPG9hdXRoQGlldGYub3JnPg0KU3Vi amVjdDogW09BVVRILVdHXSBDYWxsIGZvciBhZG9wdGlvbiBvZiAiSldUIFJlc3BvbnNlIGZvciBP QXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uIg0KDQpIaSBhbGwsDQoNClRoaXMgaXMgdGhlIGNhbGwg Zm9yIGFkb3B0aW9uIG9mIHRoZSAnSldUIFJlc3BvbnNlIGZvciBPQXV0aCBUb2tlbiBJbnRyb3Nw ZWN0aW9uJyBkb2N1bWVudCBmb2xsb3dpbmcgdGhlIHByZXNlbnRhdGlvbiBieSBUb3JzdGVuIGF0 IHRoZSBNb250cmVhbCBJRVRGIG1lZXRpbmcgd2hlcmUgd2UgZGlkbid0IGhhdmUgYSBjaGFuY2Ug dG8gZG8gYSBjYWxsIGZvciBhZG9wdGlvbiBpbiB0aGUgbWVldGluZyBpdHNlbGYuDQoNCkhlcmUg aXMgcHJlc2VudGF0aW9uIGJ5IFRvcnN0ZW46DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvMTAyL21hdGVyaWFscy9zbGlkZXMtMTAyLW9hdXRoLXNlc3NhLWp3dC1yZXNwb25z ZS1mb3Itb2F1dGgtdG9rZW4taW50cm9zcGVjdGlvbi0wMDxodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmll dGYub3JnJTJGbWVldGluZyUyRjEwMiUyRm1hdGVyaWFscyUyRnNsaWRlcy0xMDItb2F1dGgtc2Vz c2Etand0LXJlc3BvbnNlLWZvci1vYXV0aC10b2tlbi1pbnRyb3NwZWN0aW9uLTAwJmRhdGE9MDIl N0MwMSU3Q3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdDNWJiNGQxMjYxODk0NGNjOGRhNGIwOGQ1 ZWQ5ZjM4NmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2 Njc2MTkwNDc4MDc5MzY4JnNkYXRhPXd2OGUlMkZ2R0RtOUx6ZUphR3JPQkQ4b0dYZ1BTcXVORSUy QlJLaUVrbkY4c3E0JTNEJnJlc2VydmVkPTA+DQoNCkhlcmUgaXMgdGhlIGRvY3VtZW50Og0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLWp3dC1pbnRy b3NwZWN0aW9uLXJlc3BvbnNlLTAxPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJh ZnQtbG9kZGVyc3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVzcG9uc2UtMDEmZGF0YT0w MiU3QzAxJTdDdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN0M1YmI0ZDEyNjE4OTQ0Y2M4ZGE0YjA4 ZDVlZDlmMzg2YiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzY2NzYxOTA0NzgwNzkzNjgmc2RhdGE9Y0ZJU09WbWE4ZyUyQlhkdmYyS1pkd0NaQllscGZOJTJG R2Iya252OFpEOXNLejQlM0QmcmVzZXJ2ZWQ9MD4NCg0KUGxlYXNlIGxldCB1cyBrbm93IGJ5IEF1 Z3VzdCAybmQgd2hldGhlciB5b3UgYWNjZXB0IC8gb2JqZWN0IHRvIHRoZSBhZG9wdGlvbiBvZiB0 aGlzIGRvY3VtZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhlIE9BdXRoIHdv cmtpbmcgZ3JvdXAuDQoNClJlZ2FyZHMsDQpIYW5uZXMgJiBSaWZhYXQNCklNUE9SVEFOVCBOT1RJ Q0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNv bmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGlu IGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_VI1PR0801MB2112D9BE45C4F852CEAF0E4FFA510VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+VGhlcmUgYXJlIGNvbXBhbmllcyBkb2luZyB0b2tlbiBpbnRyb3NwZWN0aW9uIGJ5IHRo ZSBjbGllbnQgYWxyZWFkeSwgc2VlDQo8YSBocmVmPSJodHRwczovL2JhY2tzdGFnZS5mb3JnZXJv Y2suY29tL2RvY3MvYW0vNi9vYXV0aDItZ3VpZGUvI3NlYy1zdGFuZGFyZHMiPmh0dHBzOi8vYmFj a3N0YWdlLmZvcmdlcm9jay5jb20vZG9jcy9hbS82L29hdXRoMi1ndWlkZS8jc2VjLXN0YW5kYXJk czwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldoYXQgc2VjdXJpdHkg aW1wbGljYXRpb25zIGRvIHlvdSBzZWU/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW50aG9ueSBOYWRhbGluPGJyPg0KPGI+ U2VudDo8L2I+IDIwIEp1bHkgMjAxOCAxMDowNzxicj4NCjxiPlRvOjwvYj4gUmlmYWF0IFNoZWto LVl1c2VmOyBvYXV0aDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBDYWxsIGZv ciBhZG9wdGlvbiBvZiAmcXVvdDtKV1QgUmVzcG9uc2UgZm9yIE9BdXRoIFRva2VuIEludHJvc3Bl Y3Rpb24mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+SeKAmW0gY29uY2VybmVkIG92ZXIgdGhlIHNlY3VyaXR5IGlt cGxpY2F0aW9ucyBvZiBhIGNsaWVudCBiZWluZyBhYmxlIHRvIGludHJvc3BlY3QgYSB0b2tlbiwg Zm9yIGJlYXJlciB0b2tlbnMgdGhpcyBjYW4gYmUgdmVyeSBwcm9ibGVtYXRpYywgc28gdW5sZXNz IHRoZSBpc3N1ZXMgd2l0aCBwb3NzaWJsZSB0b2tlbiB0aGVmdCBjYW4gYmUgYWRkcmVzc2VkIEkg ZG9u4oCZdCBzdXBwb3J0DQogdGhpcyBhcyBhIFdHIGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBPQXV0aCAmbHQ7b2F1dGgtYm91 bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmlmYWF0IFNoZWtoLVl1c2Vm PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDE5LCAyMDE4IDEwOjQ0IEFNPGJyPg0K PGI+VG86PC9iPiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgJnF1b3Q7SldUIFJlc3BvbnNlIGZv ciBPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRoaXMgaXMgdGhlIGNhbGwgZm9yIGFkb3B0aW9uIG9mIHRoZSAnSldUIFJlc3Bv bnNlIGZvciBPQXV0aCBUb2tlbiBJbnRyb3NwZWN0aW9uJyBkb2N1bWVudCBmb2xsb3dpbmcgdGhl IHByZXNlbnRhdGlvbiBieSBUb3JzdGVuIGF0IHRoZSBNb250cmVhbCBJRVRGIG1lZXRpbmcgd2hl cmUgd2UgZGlkbid0IGhhdmUgYSBjaGFuY2UgdG8gZG8gYSBjYWxsIGZvciBhZG9wdGlvbiBpbg0K IHRoZSBtZWV0aW5nIGl0c2VsZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkhlcmUgaXMgcHJlc2VudGF0aW9uIGJ5IFRvcnN0ZW46PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZtZWV0aW5n JTJGMTAyJTJGbWF0ZXJpYWxzJTJGc2xpZGVzLTEwMi1vYXV0aC1zZXNzYS1qd3QtcmVzcG9uc2Ut Zm9yLW9hdXRoLXRva2VuLWludHJvc3BlY3Rpb24tMDAmYW1wO2RhdGE9MDIlN0MwMSU3Q3Rvbnlu YWQlNDBtaWNyb3NvZnQuY29tJTdDNWJiNGQxMjYxODk0NGNjOGRhNGIwOGQ1ZWQ5ZjM4NmIlN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Njc2MTkwNDc4MDc5 MzY4JmFtcDtzZGF0YT13djhlJTJGdkdEbTlMemVKYUdyT0JEOG9HWGdQU3F1TkUlMkJSS2lFa25G OHNxNCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0 aW5nLzEwMi9tYXRlcmlhbHMvc2xpZGVzLTEwMi1vYXV0aC1zZXNzYS1qd3QtcmVzcG9uc2UtZm9y LW9hdXRoLXRva2VuLWludHJvc3BlY3Rpb24tMDA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZXJlIGlzIHRoZSBkb2N1bWVudDo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFm dC1sb2RkZXJzdGVkdC1vYXV0aC1qd3QtaW50cm9zcGVjdGlvbi1yZXNwb25zZS0wMSZhbXA7ZGF0 YT0wMiU3QzAxJTdDdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN0M1YmI0ZDEyNjE4OTQ0Y2M4ZGE0 YjA4ZDVlZDlmMzg2YiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzY2NzYxOTA0NzgwNzkzNjgmYW1wO3NkYXRhPWNGSVNPVm1hOGclMkJYZHZmMktaZHdDWkJZ bHBmTiUyRkdiMmtudjhaRDlzS3o0JTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtand0LWludHJvc3BlY3Rpb24tcmVz cG9uc2UtMDE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5QbGVhc2UgbGV0IHVzIGtub3cgYnkgQXVndXN0IDJuZCB3aGV0aGVyIHlvdSBhY2NlcHQg LyBvYmplY3QgdG8gdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBw b2ludCBmb3Igd29yayBpbiB0aGUgT0F1dGggd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkhhbm5lcyAmYW1wOyBSaWZhYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9y IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR0801MB2112D9BE45C4F852CEAF0E4FFA510VI1PR0801MB2112_-- From nobody Fri Jul 20 07:18:47 2018 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 3078B130DE7 for ; Fri, 20 Jul 2018 07:18:46 -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 DUTBFs73wx0Z for ; Fri, 20 Jul 2018 07:18:43 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 4B5DB126BED for ; Fri, 20 Jul 2018 07:18:43 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id s7-v6so14860840itb.4 for ; Fri, 20 Jul 2018 07:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wHyT8MBPYD3WIDk/LSq/Aa43Xz4Gg9SPFIYjkgOiJfA=; b=NRSDrWzMjzbdt1a8P1tG92F1F4lruGqd2tHIRFQUEjNwxYWUSJwHMgZYeQ47/Z7A4n 5p4sqDcjucCgfPacpJqcJqOz+XML23i8589KGhMBZI8N0TW+5kJOdw6m35ymwLnxQcnJ Yua9gjbSNVh2LbKNj89E7fv0INvYwrL+jHhG8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wHyT8MBPYD3WIDk/LSq/Aa43Xz4Gg9SPFIYjkgOiJfA=; b=s7bIxpovynNpo1WyYpHDT0kqVr5dIf9nJM7SzQgh86uJzzEcZZ4tr0CVN+tqhCham7 7a5PzG8RjSvmaZaLkt7f+c60hRNtn91ms01ACPZZ3lY61S6ZtqugalRofiEM5tnl3HPf McvxiaQqNL3/SnBqSFAl7OwWQnQTHi2gRfAWcsaDCuDESvHpTAhKssyWCd6q303Dda7b ZZDmmhveFeQRv/53HkhwW1htauR07g0YojsdIlJbGpnWUJU6mgTOB9V5qwzHm3D5qUon QRlGMR09WeODIFL0seYxeCkBTwQnR/QxywJFq+I7iLqZs2nT1XkAbcQP1QL6SC16UkwH /q9Q== X-Gm-Message-State: AOUpUlEVCschLgMrpkSC+phXlQVenLmHZy8xP/GiVB7/GYwfCPga3+Zj qTXQ682iAOp/9mUeh99WGEHDlT93EITdDrwGDG5QeVhC+xvgODW8/nlEtUPY1zlsH/LZeOdVF0f dtqiPGh4NIsPeVQ== X-Google-Smtp-Source: AAOMgpf6vebsyljn2F9baCHh2kHkryh/nLTx5aq7+u2WwrOCRljERsiUvgbNXgq2Sq//GKUEyYGpWOLrfrkzGNjy6Ms= X-Received: by 2002:a02:3407:: with SMTP id x7-v6mr2023395jae.110.1532096322443; Fri, 20 Jul 2018 07:18:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6d18:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 07:18:11 -0700 (PDT) In-Reply-To: References: <426DBA0B-CC9B-4D9D-9ED8-5AD779159638@lodderstedt.net> From: Brian Campbell Date: Fri, 20 Jul 2018 10:18:11 -0400 Message-ID: To: Filip Skokan Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="0000000000000fbe8b05716ef9fe" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 14:18:46 -0000 --0000000000000fbe8b05716ef9fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The current draft does allow multiple "resource" parameters. However, there seemed to be consensus in the WG meeting yesterday that only a single "resource" parameter was preferable and that a client could obtain an access token per resource (likely using a refresh token). I'm personally sympathetic to that point. But maybe it's too restrictive. I would like to see some more text about the complexity implications of multiple "resource" parameters and perhaps some discouragement of doing so. I believe logical names are more potentially useful in an STS framework like token exchange but should be out of scope for this work. On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan wrote: > Hi Torsten, > > > Multiple "resource" parameters may be used to indicate that the issued > token is intended to be used at multiple resource servers. > > That's already in. Furthermore what about logical names for target > services? Like was added in -03 of token exchange? > > Best, > *Filip Skokan* > > > On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> I support adoption of this document. >> >> I would like to point out (again) a single resource is not sufficient fo= r >> most use cases I implemented in the last couple if years. I=E2=80=98m ad= vocating >> for enhancing the draft to support multiple resources and a clear >> definition of the relationship between resource(s) and scope. >> >> Am 20.07.2018 um 08:20 schrieb n-sakimura : >> >> +1 >> >> >> >> *From:* OAuth [mailto:oauth-bounces@ietf.org ] *= On >> Behalf Of *Brian Campbell >> *Sent:* Friday, July 20, 2018 7:42 AM >> *To:* Rifaat Shekh-Yusef >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for >> OAuth 2.0" >> >> >> >> I support adoption of this document. >> >> >> >> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef < >> rifaat.ietf@gmail.com> wrote: >> >> Hi all, >> >> This is the call for adoption of the 'Resource Indicators for OAuth 2.0' >> document >> following the positive call for adoption at the Montreal IETF meeting. >> >> Here is the document: >> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 >> >> Please let us know by August 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >> >> Regards, >> Rifaat >> >> >> _______________________________________________ >> 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 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 _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._ --0000000000000fbe8b05716ef9fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current draft does allow multiple "resource&= quot; parameters. However, there seemed to be consensus in the WG meeting y= esterday that only a single "resource" parameter was preferable a= nd that a client could obtain an access token per resource (likely using a = refresh token). I'm personally sympathetic to that point. But maybe it&= #39;s too restrictive. I would like to see some more text about the complex= ity implications of multiple "resource" parameters and perhaps so= me discouragement of doing so. I believe logical names are more potentially= useful in an STS framework like token=C2=A0exchange but should be out of s= cope for this work. =C2=A0






On Fri, Jul 20, 2018 at 3:43 AM, F= ilip Skokan <panva.ip@gmail.com> wrote:
Hi Torsten,

&= gt;=C2=A0Multiple "resource" parameters may be used to indicate t= hat the issued token is intended to be used at multiple resource servers.

That's already in. Furthermore what about logic= al names for target services? Like was added in -03 of token exchange?
Best,
Filip Skokan


= On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt <torsten@lodderstedt.net> w= rote:
=
I support adoption of this document.

I would = like to point out (again) a single resource is not sufficient for most use = cases I implemented in the last couple if years. I=E2=80=98m advocating for= enhancing the draft to support multiple resources and a clear definition o= f the relationship between resource(s) and scope.

Am 20.07.20= 18 um 08:20 schrieb n-sakimura <n-sakimura@nri.co.jp>:

+1

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On B= ehalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicat= ors for OAuth 2.0"

=C2=A0

I support adoption of this document. <= /p>

=C2=A0

On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef = <rifaat.ietf@= gmail.com> wrote:

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-i= ndicators-02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat


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

=C2=A0


CONFIDENTIAL= ITY 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..=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 attach= ments from your computer. Thank you.

___________________= ____________________________
OAuth mailing list=
OAuth@ietf.or= g
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



<= 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. --0000000000000fbe8b05716ef9fe-- From nobody Fri Jul 20 07:20:19 2018 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 E8F9B130DE7 for ; Fri, 20 Jul 2018 07:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2xsmQh-YIfaA for ; Fri, 20 Jul 2018 07:20:14 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) (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 D9057130DCE for ; Fri, 20 Jul 2018 07:20:13 -0700 (PDT) Received: from [80.187.105.187] (helo=[10.20.204.47]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fgWGQ-00015a-0z; Fri, 20 Jul 2018 16:20:10 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-152BF982-4FB9-4AD8-A4AF-D23D2CCFBB67; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Fri, 20 Jul 2018 16:20:09 +0200 Cc: Rifaat Shekh-Yusef , oauth Content-Transfer-Encoding: 7bit Message-Id: References: To: Anthony Nadalin X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 14:20:18 -0000 --Apple-Mail-152BF982-4FB9-4AD8-A4AF-D23D2CCFBB67 Content-Type: multipart/alternative; boundary=Apple-Mail-5FECF17D-E4E3-4EB2-9891-31A6A2DF3E4D Content-Transfer-Encoding: 7bit --Apple-Mail-5FECF17D-E4E3-4EB2-9891-31A6A2DF3E4D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 20.07.2018 um 16:06 schrieb Anthony Nadalin : >=20 > I=E2=80=99m concerned over the security implications of a client being abl= e to introspect a token, for bearer tokens this can be very problematic, so u= nless the issues with possible token theft can be addressed I don=E2=80=99t s= upport this as a WG draft Hi Tony, I think this an issue for introspection in general and not specific to our e= xtension. If the token content needs to be kept confidential then the AS MUST authenti= cate the caller of the Introspection endpoint and apply an suitable authz po= licy. This is possible with Token Introspection and with our draft as well.=20= Additionally, our draft allows to encrypt the token response, adding an extr= a layer of defense.=20 kind regards, Torsten. > =20 > From: OAuth On Behalf Of Rifaat Shekh-Yusef > Sent: Thursday, July 19, 2018 10:44 AM > To: oauth > Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Int= rospection" > =20 > Hi all, > =20 > This is the call for adoption of the 'JWT Response for OAuth Token Introsp= ection' document following the presentation by Torsten at the Montreal IETF m= eeting where we didn't have a chance to do a call for adoption in the meetin= g itself. > =20 > Here is presentation by Torsten: > https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-= jwt-response-for-oauth-token-introspection-00 > =20 > Here is the document: > https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-01 > =20 > Please let us know by August 2nd whether you accept / object to the adopti= on of this document as a starting point for work in the OAuth working group.= > =20 > Regards, > Hannes & Rifaat > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-5FECF17D-E4E3-4EB2-9891-31A6A2DF3E4D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Am 20.07.201= 8 um 16:06 schrieb Anthony Nadalin <tonynad=3D40microsoft.com@dmarc.ietf.org>:
=

I=E2=80=99m concerned over the security implications o= f a client being able to introspect a token, for bearer tokens this can be v= ery problematic, so unless the issues with possible token theft can be addre= ssed I don=E2=80=99t support this as a WG draft

=

Hi Tony,

I think this an issue for introsp= ection in general and not specific to our extension.

If the token content needs to be kept confidential then the AS MUST authen= ticate the caller of the Introspection endpoint and apply an suitable authz p= olicy. This is possible with Token Introspection and with our draft as well.=  

Additionally, our draft allows to encrypt th= e token response, adding an extra layer of defense. 

kind regards,
Torsten.

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 10:44 AM
To: oauth <oauth@ietf.org>= ;
Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Toke= n Introspection"

 

Hi all,

 

This is the call for adoption of the 'JWT Response fo= r OAuth Token Introspection' document following the presentation by Torsten a= t the Montreal IETF meeting where we didn't have a chance to do a call for a= doption in the meeting itself.

 

Here is presentation by Torsten:

 

Here is the document:

 

Please let us know by August 2nd whether you accept /= object to the adoption of this document as a starting point for work in the= OAuth working group.

 

Regards,

Hannes & Rifaat

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-5FECF17D-E4E3-4EB2-9891-31A6A2DF3E4D-- --Apple-Mail-152BF982-4FB9-4AD8-A4AF-D23D2CCFBB67 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyMDE0MjAwOVowIwYJKoZIhvcNAQkEMRYE FDLKjAUAk/mjgLbJxlzOXRFTrVcVMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQB0hPOVQjqzeIo/k/v2rv28+K9r0AAg iv7tqkWEkN1xLVAIihCYh2K7zdoDS4bOIPVOvnjw9xXZW9vGlT56ybnx0ZIusR72ge7z3cR4wuO2 CBoVkiuidld4helj5qhQKLOtXSr/tTJZB41UmedXmBAf45Yap1U0eVJejK2NZ0g1vMVpa8jiBjp6 /OcsGPgIJLxaOSutIZcGtwxIQhJozL8N8A7kvQzxvSPQX1jjlE5Ok4s+rGCq05wJJkF5CPHyS0/J rY/0XZUpEhG+IrdlrcfsAdQBQKLleP2XCofSNLe5QG+jf1t28wjbdP7upOyBnptdFqWRQcIZ28Ud 6O/JIR/2AAAAAAAA --Apple-Mail-152BF982-4FB9-4AD8-A4AF-D23D2CCFBB67-- From nobody Fri Jul 20 07:22:19 2018 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 BAA51131195 for ; Fri, 20 Jul 2018 07:22:11 -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 xpbBZ8fRtMw6 for ; Fri, 20 Jul 2018 07:22:09 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 2A05B130E3B for ; Fri, 20 Jul 2018 07:22:09 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id y10-v6so10068052ioa.10 for ; Fri, 20 Jul 2018 07:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WOEgNcOtgiCvRdk6uSJru5PZ1IEEYoS03sm/w2lYk+E=; b=hveD+GOO0UPsuyacdTH5TzPz6VCp1YzFwy9PMvGwyR3PG1pcC0REw9o3Cbnx9SNZLB EnLKrZBBQESgHH99t3y7g5gEwgI/bhjkPy3dd9Hs/UIxfdH8r9q+Y4BDvFTg3Spoh5QC Q91G20Ozn/T/lGTxzOi+OPidRRkPr5fnhTJhI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WOEgNcOtgiCvRdk6uSJru5PZ1IEEYoS03sm/w2lYk+E=; b=ICBBFIAc+8k0CgqqI4fEDvNgvZIzoENIL7H/uLRDvB0U/NOzIWSwoQ9Rx4FcVqu4MB QwMfvm9GJm9eLNnyl4unKJ1WpqlF2Q3OPLe+3g4mxI+tWYpWlbB4rN3rXSad1c0kxA8K SNEXX+ffqPQM0BTgxYk82A2ZJ4TdvKtmMIqOBGTmFi6tEy+zQUix89nxzTKNf6brOyDX kF09Vl4rFWxKG2SyEB6v6cUVKoQLF9Y65vCw38Ny9okuLroNGCtXlzUckyg8Zy9Gow+x pQX+iSx4ZsrZmq0iHtTqZVAVFdLre/VxlV7XAZVahltTBc/dvLFqYk+ftOBihFOdaueb Mv4w== X-Gm-Message-State: AOUpUlG1WcdOSXIs2aFpIRpslh9HBqttNpWYiGaTknEmDQVrjIr8btzh FfRrjnM1+K4pQRguChBc8pyv6Nq7DgDYbld8mlKAZlzjKF1Prh85PBCGe6q4Ymm4adrTyCO8+S3 aGG/dIFH2H+nCgA== X-Google-Smtp-Source: AAOMgpfziIUTYLBzJ5W+LuiUIJ7FZLLTbdsw6mK1yxw21rrX3HOQT0tlzd/bFgsg9hOrdzeslqXYBb+ZCfDtR7EXdo8= X-Received: by 2002:a6b:d90d:: with SMTP id r13-v6mr1844314ioc.247.1532096528432; Fri, 20 Jul 2018 07:22:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6d18:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 07:21:37 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 20 Jul 2018 10:21:37 -0400 Message-ID: To: William Denniss Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="00000000000056dea105716f0546" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 14:22:18 -0000 --00000000000056dea105716f0546 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Thu, Jul 19, 2018 at 1:51 PM, William Denniss < wdenniss=3D40google.com@dmarc.ietf.org> wrote: > I support adoption of this document by the working group. > > > On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com> wrote: > >> Hi all, >> >> This is the call for adoption of the 'JWT Response for OAuth Token >> Introspection' document following the presentation by Torsten at the >> Montreal IETF meeting where we didn't have a chance to do a call for >> adoption in the meeting itself. >> >> Here is presentation by Torsten: >> https://datatracker.ietf.org/meeting/102/materials/slides-10 >> 2-oauth-sessa-jwt-response-for-oauth-token-introspection-00 >> >> Here is the document: >> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-intr >> ospection-response-01 >> >> Please let us know by August 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth work= ing >> group. >> >> Regards, >> Hannes & Rifaat >> >> _______________________________________________ >> 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._ --00000000000056dea105716f0546 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Thu, Jul 19, 2018 at 1:51 PM, William Denniss &= lt;wdenniss=3D40google.com@dmarc.ietf.org> wrote:
I support adoption of this documen= t by the working group.

=
On Thu, Jul 19, 2018 = at 10:43 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> = wrote:
Hi all,

This is the call fo= r adoption of the 'JWT Response for OAuth Token Introspection' docu= ment following the presentation by Torsten at the Montreal IETF meeting whe= re we didn't have a chance to do a call for adoption in the meeting its= elf.

Here is presentation by Torsten:
ht= tps://datatracker.ietf.org/meeting/102/materials/slides-102-oauth= -sessa-jwt-response-for-oauth-token-introspection-00
Here is the document:

Please let us know by A= ugust 2nd whether you accept / object to the adoption of this document as a= starting point for work in the OAuth working group.

Regards,
Hannes & Rifaat

_______________________________________________
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. --00000000000056dea105716f0546-- From nobody Fri Jul 20 07:25:51 2018 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 6D645130E3B for ; Fri, 20 Jul 2018 07:25:49 -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_REMOTE_IMAGE=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=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 pb20-HYBK3nl for ; Fri, 20 Jul 2018 07:25:46 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::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 B6EF4130E2E for ; Fri, 20 Jul 2018 07:25:46 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id b1-v6so5270214pls.5 for ; Fri, 20 Jul 2018 07:25:46 -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=LTYtssZQ2uWGUbzbRQotCVW51cm9xiV8IUeZmsGD50E=; b=alam9bU3xaMoC2kADDVK7TSZDYBmJgWUPUdXng3oOJ02qe3IgbK0kOtYhl8Cys3Plt 0FJU5rTOtLQFgSJunRBwqvdVVamey4WwFQ/sNUtLnlniI9ZtBSS7cWFAhz6HviHsRTho o513pQFey7PzehGMirhrzoMtZ0laVPwfN7oT0= 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=LTYtssZQ2uWGUbzbRQotCVW51cm9xiV8IUeZmsGD50E=; b=hDsF2DyxvwrEX+8MdEq8Y79B/dZBzrw7TjQgAoB/2EWjwei9O5uN8oUHwhbKUC+p15 agBgP+gfJ6kkGVBHI4fm7F5XEWqlxjyctCAtZInfLj3laWSL1bBEO9meNm1KUg7ezE+k oQGksrTVezQeRMOs0epVkrIJegREKKJtlW4Sw3BgzutskOlPV1EGiZueVitYjzjU3oT8 FpUetqAjaClhQEKg6YZcox+4hY2bqAbRN2nkCx4bQRZGPbISq0P6u7l+2TV6f3gz7iSe 85CJwYboC+LG3yExz4LTV78lJV7SFiNvvRousBLjYAxKIpOUMrrzBsVXZka1QqXSiRb9 RRXA== X-Gm-Message-State: AOUpUlHZJQadUk5JedN6Yc1WZyd2LdtkcSXV0G5L+9smjCDCNcni4b1T fND6jtK9JFM8pd0Zbiw42wXnmGaIkwvvOt4bxU9ZxtwWjFysI11csR9fF1ACt124oDYd3G94HD9 GL65c5amy1tnrUfht X-Google-Smtp-Source: AAOMgpe2RdiG2r61bfinAKXgaAdOJ4VBA8306kCZ97lJxoOudIYKOFQK9sV97QQpi5egFFIuMq6nzVWGnL+78iIFmhc= X-Received: by 2002:a17:902:20e9:: with SMTP id v38-v6mr2328867plg.107.1532096746069; Fri, 20 Jul 2018 07:25:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Otto Date: Fri, 20 Jul 2018 15:25:35 +0100 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000004fb3d105716f1265" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 14:25:50 -0000 --0000000000004fb3d105716f1265 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support this as well On Fri, 20 Jul 2018 at 15:22, Brian Campbell wrote: > +1 > > On Thu, Jul 19, 2018 at 1:51 PM, William Denniss < > wdenniss=3D40google.com@dmarc.ietf.org> wrote: > >> I support adoption of this document by the working group. >> >> >> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef < >> rifaat.ietf@gmail.com> wrote: >> >>> Hi all, >>> >>> This is the call for adoption of the 'JWT Response for OAuth Token >>> Introspection' document following the presentation by Torsten at the >>> Montreal IETF meeting where we didn't have a chance to do a call for >>> adoption in the meeting itself. >>> >>> Here is presentation by Torsten: >>> >>> https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-ses= sa-jwt-response-for-oauth-token-introspection-00 >>> >>> Here is the document: >>> >>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-r= esponse-01 >>> >>> Please let us know by August 2nd whether you accept / object to the >>> adoption of this document as a starting point for work in the OAuth wor= king >>> group. >>> >>> Regards, >>> Hannes & Rifaat >>> >>> _______________________________________________ >>> 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 > --=20 [image: Ping Identity] Rob Otto EMEA Field CTO/Solutions Architect robertotto@pingidentity.com c: +44 (0) 777 135 6092 Connect with us: [image: Glassdoor logo] [image: LinkedIn logo] [image: twitter logo] [image: facebook logo] [image: youtube logo] [image: Google+ logo] [image: Blog logo] --=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._ --0000000000004fb3d105716f1265 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support this as well=C2=A0

On Fri, 20 Jul 2018 at 15:22, Brian C= ampbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
+1

On Thu, Jul 19, 2018 at 1:51 PM, William Denniss <wdenniss=3D40google.com@dmarc.ietf.org> w= rote:
I support adoption= of this document by the working group.


On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi all,

This is the call for adoption of = the 'JWT Response for OAuth Token Introspection' document following= the presentation by Torsten at the Montreal IETF meeting where we didn'= ;t have a chance to do a call for adoption in the meeting itself.

Here is presentation by Torsten:

Here is the docum= ent:
Please let us know by August 2nd whether you accept / object t= o the adoption of this document as a starting point for work in the OAuth w= orking group.

Regards,
Hannes & Rifa= at

_______________________________________________
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 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


--
3D"Ping=
Rob Otto
EMEA Field CTO/Solu= tions Architect
robertott= o@pingidentity.com

= = c: +44 (0) 777 135 6092
=
Connect = with us: = 3D"Glassdoor 3D"LinkedIn = 3D"facebook 3D"youtube 3D"Google+= 3D"Blog

<= 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. --0000000000004fb3d105716f1265-- From nobody Fri Jul 20 07:26:27 2018 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 EC893130E3B for ; Fri, 20 Jul 2018 07:26:24 -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 zfeY5LTLPCpH for ; Fri, 20 Jul 2018 07:26:23 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 C23B7130E2E for ; Fri, 20 Jul 2018 07:26:22 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 16-v6so14897553itl.5 for ; Fri, 20 Jul 2018 07:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AMn9lB63q9k9ImXLDe9vTqUxpSyPxDBB334O6+uBqx4=; b=jqavWe2JplBtPA3KS2zQqjXCgb5Hx7betnZMqn2hZvt3sU37AYRicr6LHydlobKgF4 xDrH9v058zZmeO3+yVMIlAqwhAp7Dc47EwNJHZBnDLZzt0Zr4I/gK7ZkM4jenzBgAKOF 5JSMVmD95USh7AsLW17yCUIgbMHrbnQuP9Xyw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AMn9lB63q9k9ImXLDe9vTqUxpSyPxDBB334O6+uBqx4=; b=ZZ3zDBW5FmuFxVDu/Fkp4SZc2YTY1BhH5BoXOgzq+6uo2BMfy4ZpFOwTi1zY6gbXrI tVV8bojTtosuERhJeJj1P6mRMQxmwHlNmbOe7bJ8yyegzefLzA4Q3XneWBlLBbnix+4X 3eQT41yfHtmCtK1kprzFPUQ6MkAsX9lPeO8HKQgFamZmNyF+i7WMmqqZQvRjucres826 8t6r/RRb+GvQdrxOoMJUJO9yzqvbURgrVC0EVyZ+c++NaHJdyuVdDDYEIDJhGN7i1PIA SOqxuRlb7oMpQkgetNbx37Xgvyq8RdBCEoFbWW4+nTFFfTh6cctCxPxoJPFJEYjpYMv5 /JmQ== X-Gm-Message-State: AOUpUlEHqxQ9/ivzCjPptM26RZuyaYaysf5aRyFeaQa9y3F+nnyviMRL p8NfpumaLDGQ/aoiFu88U0OMPDqiO5GpN8/Qf46xEH6Xk/ONnkYoCYlg4OsiMiNbm/P+AtE+L3k w5NX/ZHRqtUJ0NQ== X-Google-Smtp-Source: AAOMgpddDjGqKiGV56jQDE6vLMZpefN1nOQfA0efW0WoL0b3Hx4jpTKgWPIJIdtz/VIT+mKev7yhszGGeSBRBOiXtBE= X-Received: by 2002:a02:3407:: with SMTP id x7-v6mr2050318jae.110.1532096782033; Fri, 20 Jul 2018 07:26:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6d18:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 07:25:51 -0700 (PDT) In-Reply-To: <42FCE1EF-1470-4F29-86D4-8DEFCC823452@lodderstedt.net> References: <42FCE1EF-1470-4F29-86D4-8DEFCC823452@lodderstedt.net> From: Brian Campbell Date: Fri, 20 Jul 2018 10:25:51 -0400 Message-ID: To: Torsten Lodderstedt Cc: n-sakimura , oauth Content-Type: multipart/alternative; boundary="00000000000074767d05716f1402" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 14:26:25 -0000 --00000000000074767d05716f1402 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 with the expectation (as discussed in the WG meeting) that it'll be reconciled with the "resource" draft with references as appropriate On Fri, Jul 20, 2018 at 3:28 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > +1 > > Am 20.07.2018 um 08:21 schrieb n-sakimura : > > And if it were not obvious, YES J > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Dick Hardt > *Sent:* Friday, July 20, 2018 6:12 AM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for adoption for "Distributed OAuth" > > > > I'm supportive. :) > > > > On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef > wrote: > > Hi all, > > > > This is the call for adoption of the 'Distributed OAuth' document > > following the positive call for adoption at the Montreal IETF meeting. > > > > Here is the document: > > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ > > > > Please let us know by August 2nd whether you accept / object to the > > adoption of this document as a starting point for work in the OAuth > > working group. > > > > Regards, > > Hannes & Rifaat > > > > > _______________________________________________ > 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 _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._ --00000000000074767d05716f1402 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 with the expectation (as discussed in the WG meeting) t= hat it'll be reconciled with the "resource" draft with refere= nces as appropriate

On Fri, Jul 20, 2018 at 3:28 AM, Torsten Lodderstedt <t= orsten@lodderstedt.net> wrote:
+1
<= br>Am 20.07.2018 um 08:21 schrieb n-sakimura <n-sakimura@nri.co.jp>:

=

And if it were not obvious, YES J

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On B= ehalf Of Dick Hardt
Sent: Friday, July 20, 2018 6:12 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAut= h"

=C2=A0

I'm supportive. :)

=C2=A0

On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef = <rifaat.ietf@= gmail.com> wrote:

Hi all,

=C2=A0

This is the call for adoption of the 'Distribute= d OAuth' document

following the positive call for adoption at the Mont= real IETF meeting.

=C2=A0

Here is the document:

=C2=A0

Please let us know by August 2nd whether you accept = / object to the

adoption of this document as a starting point for wo= rk in the OAuth

working group.

=C2=A0

Regards,

Hannes & Rifaat

=C2=A0


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

=C2=A0

___________________= ____________________________
OAuth mailing list=
OAuth@ietf.or= g
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. --00000000000074767d05716f1402-- From nobody Fri Jul 20 08:13:55 2018 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 E647E131053 for ; Fri, 20 Jul 2018 08:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 MszAmqYwcCDQ for ; Fri, 20 Jul 2018 08:13:49 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640105.outbound.protection.outlook.com [40.107.64.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58ED4130DCC for ; Fri, 20 Jul 2018 08:13:49 -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=vph+zRJScmeyqecHSqorW4swtwdv9sUZflXQrIkwCVo=; b=lnCxbBPogd7ZefW4Fzp7Qikgmw0thQ52FQ1gOLAeXbUjOFa3QZNW/Wi0yn6JO3JNO3GzV1aMkTnud2yozRpOdCVf3UmM/o0wuA1KVZRzaDsc/Hte6imTfdqfJ9Ormvuni3gmsBLatZl9kozIZjWUeGPCvoDa0iec6CusyttW33c= Received: from MW2PR00MB0300.namprd00.prod.outlook.com (52.132.148.31) by MW2PR00MB0297.namprd00.prod.outlook.com (52.132.148.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1016.0; Fri, 20 Jul 2018 15:13:47 +0000 Received: from MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::75b7:1894:dd72:4ede]) by MW2PR00MB0300.namprd00.prod.outlook.com ([fe80::75b7:1894:dd72:4ede%9]) with mapi id 15.20.1019.000; Fri, 20 Jul 2018 15:13:47 +0000 From: Mike Jones To: Brian Campbell , Filip Skokan CC: oauth Thread-Topic: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" Thread-Index: AQHUH5tpAEJtgz4Ml0eD0vJ2JOwxQKSXJEAAgAB/7ICAABQvgIAAAxYAgABuUoCAAA7yUA== Date: Fri, 20 Jul 2018 15:13:47 +0000 Message-ID: References: <426DBA0B-CC9B-4D9D-9ED8-5AD779159638@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1232:144:b451:cffc:cd3a:d087] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR00MB0297; 6:ohkhPZmU0LAVqZwGyTN26XtLZPsfw1CvZjLB+GyBK+xFmHetaTUR/BC43HwQJ01k4qwtMdVcw6DILs4r6wkn+QMpRb/dIx/IwfQpLriqVeQZ91/csK/Cf7qoaurEDUTepogWEYCs+hJuHKSADUXdPabZdwVuBHAwM6EsIhjaDwwaFFg+ezAOWURhC/Z4cmWFfiiV87emA0ZcFjZ/ERTvp5pE/sET1GI76lOHc/IOgB3JihHrieXEMW9ypmutCpdXuWz9IsvebypB2Ruf0IlZLH8gz+EhUphQtc8xL6IgkfviMFdaGAbqhtgNFyvrVlSQLZzEzRMXI/j69+DJoHPDALvcOjmI78PAuJuRBxZcQ3GNtcgH/+9opZS0hZDdgSVTQ8rccYv1vSe7sgHuFHRMJO9b6vptq/YXFWs7cApexdzIy30+dqY9o2QhULoXseEcR+xZmCVRFcrAvSv/u0Yy6Q==; 5:tzZyY4tSihbTPuFM5Sx94Hti0QMdXImeFJyAqlfnqHrwJ0gUFT6hWvra0txRqxeysXc7ne7JdRtF93b2ZErAyysivBAbMnUuPKsWibobB0OafZbF4GHOZoPG1U+ALAHSLz2IGLqp9/AXM7OrYUyE0zpUeqpKa7RsZtjYg96kZQ4=; 7:50UFFC1hfWGGYeJ6HwLu+xlv7KOn6ypX1xV8TNSb/aubPw4l00JP1sDsLOYwRuZp63x45Qe9e2u1r8BeRA196ndo7nfXKGjCSd9ZmlSMK9aP3MbpP78ks8LFJJ2Ns+3vYc+webgnGAbjHorzBMFe6YpnWGZctHoCbVWN+UFl/kGl6nHqPFJ0ANi4ODkZQ5zmf+nnzQ/X33oxj3p5cdCe2W3iAJG5nTjNg+5WEVyodhXYFv1kUDazvd4YPvUltIzO x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a8e95315-3e1d-4a1e-71bd-08d5ee536454 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:MW2PR00MB0297; x-ms-traffictypediagnostic: MW2PR00MB0297: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(85827821059158)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(2018427008)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MW2PR00MB0297; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0297; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(346002)(396003)(366004)(376002)(189003)(199004)(53754006)(256004)(53936002)(9686003)(6436002)(236005)(476003)(86362001)(8936002)(2906002)(55016002)(790700001)(5250100002)(105586002)(106356001)(6306002)(81166006)(68736007)(25786009)(54896002)(8676002)(6116002)(486006)(10090500001)(446003)(99286004)(11346002)(606006)(19609705001)(86612001)(97736004)(81156014)(14444005)(7736002)(6506007)(110136005)(10290500003)(4326008)(39060400002)(478600001)(2900100001)(7696005)(8990500004)(186003)(316002)(53546011)(46003)(33656002)(74316002)(229853002)(966005)(93886005)(72206003)(5660300001)(14454004)(5024004)(102836004)(76176011)(22452003)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0297; H:MW2PR00MB0300.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) x-microsoft-antispam-message-info: 9yJeAZcIsFHr4mO873lp3WeEljNUpnsiRBce3VGhWYdUoF0dQoKuQ7uA5uom/UBIA3HY9jQDtKP7KrCiu6NJOyiP4jQZssPk94eKMrG7lxP6iqmM6kY24oPdO4kvC5SuET/7QGHLuPBzeRo4nDLqf0sqge7V2ZekkAMX9KpXxMqdgblLKjf//uDQEd+jtXJbq4Y5+yyNK59p/rEJlaHucjJVEdhPByOi5iWGDRMEOEBScUJlmDSLDeQd8WBideNglQERTFvnW2t2BxUsA9dOUFswdjR9E7uLoL28EMijIBAo/giM3tGZNqtQk8kFesdyjBm5GHba8+mGnZA3CaASFK6wpYYCn0VVSrGp6fKxNKI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR00MB0300E556CAC7F285C11DB784F5510MW2PR00MB0300namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a8e95315-3e1d-4a1e-71bd-08d5ee536454 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 15:13:47.4294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0297 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 15:13:53 -0000 --_000_MW2PR00MB0300E556CAC7F285C11DB784F5510MW2PR00MB0300namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hpbGUgSSBhZ3JlZSB0aGF0IGEgc2luZ2xlIHJlcXVlc3RlZCByZXNvdXJjZSBpcyB0aGUgY29t bW9uIGNhc2UsIGVub3VnaCBwZW9wbGUgaGF2ZSBzcG9rZW4gdXAgd2l0aCBhIG5lZWQgZm9yIG11 bHRpcGxlIHJlcXVlc3RlZCByZXNvdXJjZXMgb3ZlciB0aGUgeWVhcnMgdGhhdCBJIHRoaW5rIGV2 ZXJ5b25lIHdpbGwgYmUgYmV0dGVyIHNlcnZlZCBieSBsZWF2aW5nIHRoZSBhYmlsaXR5IHRvIHNw ZWNpZnkgbXVsdGlwbGUgcmVxdWVzdGVkIHJlc291cmNlcyBpbiB0aGUgc3BlY2lmaWNhdGlvbi4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tIE1pa2UNCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogRnJpZGF5LCBKdWx5IDIwLCAyMDE4IDEwOjE4IEFN DQpUbzogRmlsaXAgU2tva2FuIDxwYW52YS5pcEBnbWFpbC5jb20+DQpDYzogb2F1dGggPG9hdXRo QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb24gZm9y ICJSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAiDQoNClRoZSBjdXJyZW50IGRyYWZ0 IGRvZXMgYWxsb3cgbXVsdGlwbGUgInJlc291cmNlIiBwYXJhbWV0ZXJzLiBIb3dldmVyLCB0aGVy ZSBzZWVtZWQgdG8gYmUgY29uc2Vuc3VzIGluIHRoZSBXRyBtZWV0aW5nIHllc3RlcmRheSB0aGF0 IG9ubHkgYSBzaW5nbGUgInJlc291cmNlIiBwYXJhbWV0ZXIgd2FzIHByZWZlcmFibGUgYW5kIHRo YXQgYSBjbGllbnQgY291bGQgb2J0YWluIGFuIGFjY2VzcyB0b2tlbiBwZXIgcmVzb3VyY2UgKGxp a2VseSB1c2luZyBhIHJlZnJlc2ggdG9rZW4pLiBJJ20gcGVyc29uYWxseSBzeW1wYXRoZXRpYyB0 byB0aGF0IHBvaW50LiBCdXQgbWF5YmUgaXQncyB0b28gcmVzdHJpY3RpdmUuIEkgd291bGQgbGlr ZSB0byBzZWUgc29tZSBtb3JlIHRleHQgYWJvdXQgdGhlIGNvbXBsZXhpdHkgaW1wbGljYXRpb25z IG9mIG11bHRpcGxlICJyZXNvdXJjZSIgcGFyYW1ldGVycyBhbmQgcGVyaGFwcyBzb21lIGRpc2Nv dXJhZ2VtZW50IG9mIGRvaW5nIHNvLiBJIGJlbGlldmUgbG9naWNhbCBuYW1lcyBhcmUgbW9yZSBw b3RlbnRpYWxseSB1c2VmdWwgaW4gYW4gU1RTIGZyYW1ld29yayBsaWtlIHRva2VuIGV4Y2hhbmdl IGJ1dCBzaG91bGQgYmUgb3V0IG9mIHNjb3BlIGZvciB0aGlzIHdvcmsuDQoNCg0KDQoNCg0KDQoN Ck9uIEZyaSwgSnVsIDIwLCAyMDE4IGF0IDM6NDMgQU0sIEZpbGlwIFNrb2thbiA8cGFudmEuaXBA Z21haWwuY29tPG1haWx0bzpwYW52YS5pcEBnbWFpbC5jb20+PiB3cm90ZToNCkhpIFRvcnN0ZW4s DQoNCj4gTXVsdGlwbGUgInJlc291cmNlIiBwYXJhbWV0ZXJzIG1heSBiZSB1c2VkIHRvIGluZGlj YXRlIHRoYXQgdGhlIGlzc3VlZCB0b2tlbiBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIGF0IG11bHRp cGxlIHJlc291cmNlIHNlcnZlcnMuDQoNClRoYXQncyBhbHJlYWR5IGluLiBGdXJ0aGVybW9yZSB3 aGF0IGFib3V0IGxvZ2ljYWwgbmFtZXMgZm9yIHRhcmdldCBzZXJ2aWNlcz8gTGlrZSB3YXMgYWRk ZWQgaW4gLTAzIG9mIHRva2VuIGV4Y2hhbmdlPw0KDQpCZXN0LA0KRmlsaXAgU2tva2FuDQoNCg0K T24gRnJpLCBKdWwgMjAsIDIwMTggYXQgOTozMyBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90 ZToNCkkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQpJIHdvdWxkIGxpa2Ug dG8gcG9pbnQgb3V0IChhZ2FpbikgYSBzaW5nbGUgcmVzb3VyY2UgaXMgbm90IHN1ZmZpY2llbnQg Zm9yIG1vc3QgdXNlIGNhc2VzIEkgaW1wbGVtZW50ZWQgaW4gdGhlIGxhc3QgY291cGxlIGlmIHll YXJzLiBJ4oCYbSBhZHZvY2F0aW5nIGZvciBlbmhhbmNpbmcgdGhlIGRyYWZ0IHRvIHN1cHBvcnQg bXVsdGlwbGUgcmVzb3VyY2VzIGFuZCBhIGNsZWFyIGRlZmluaXRpb24gb2YgdGhlIHJlbGF0aW9u c2hpcCBiZXR3ZWVuIHJlc291cmNlKHMpIGFuZCBzY29wZS4NCg0KQW0gMjAuMDcuMjAxOCB1bSAw ODoyMCBzY2hyaWViIG4tc2FraW11cmEgPG4tc2FraW11cmFAbnJpLmNvLmpwPG1haWx0bzpuLXNh a2ltdXJhQG5yaS5jby5qcD4+Og0KKzENCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IEZyaWRheSwg SnVseSAyMCwgMjAxOCA3OjQyIEFNDQpUbzogUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0 ZkBnbWFpbC5jb208bWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbT4+DQpDYzogb2F1dGggPG9h dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBDYWxsIGZvciBhZG9wdGlvbiBmb3IgIlJlc291cmNlIEluZGljYXRvcnMgZm9yIE9BdXRo IDIuMCINCg0KSSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQoNCk9uIFRodSwg SnVsIDE5LCAyMDE4IGF0IDQ6MDEgUE0sIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZA Z21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkhpIGFsbCwN Cg0KVGhpcyBpcyB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb2YgdGhlICdSZXNvdXJjZSBJbmRpY2F0 b3JzIGZvciBPQXV0aCAyLjAnIGRvY3VtZW50DQpmb2xsb3dpbmcgdGhlIHBvc2l0aXZlIGNhbGwg Zm9yIGFkb3B0aW9uIGF0IHRoZSBNb250cmVhbCBJRVRGIG1lZXRpbmcuDQoNCkhlcmUgaXMgdGhl IGRvY3VtZW50Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9h dXRoLXJlc291cmNlLWluZGljYXRvcnMtMDINCg0KUGxlYXNlIGxldCB1cyBrbm93IGJ5IEF1Z3Vz dCAybmQgd2hldGhlciB5b3UgYWNjZXB0IC8gb2JqZWN0IHRvIHRoZQ0KYWRvcHRpb24gb2YgdGhp cyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGluIHRoZSBPQXV0aA0Kd29y a2luZyBncm91cC4NCg0KUmVnYXJkcywNClJpZmFhdA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk Li4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRo ZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRo YW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0 cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4u ICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUg bWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFu ayB5b3UuDQo= --_000_MW2PR00MB0300E556CAC7F285C11DB784F5510MW2PR00MB0300namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPldoaWxlIEkgYWdyZWUgdGhh dCBhIHNpbmdsZSByZXF1ZXN0ZWQgcmVzb3VyY2UgaXMgdGhlIGNvbW1vbiBjYXNlLCBlbm91Z2gg cGVvcGxlIGhhdmUgc3Bva2VuIHVwIHdpdGggYSBuZWVkIGZvciBtdWx0aXBsZSByZXF1ZXN0ZWQg cmVzb3VyY2VzIG92ZXIgdGhlIHllYXJzIHRoYXQgSSB0aGluayBldmVyeW9uZSB3aWxsIGJlIGJl dHRlciBzZXJ2ZWQgYnkgbGVhdmluZw0KIHRoZSBhYmlsaXR5IHRvIHNwZWNpZnkgbXVsdGlwbGUg cmVxdWVzdGVkIHJlc291cmNlcyBpbiB0aGUgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBPQXV0aCAmbHQ7b2F1dGgtYm91bmNl c0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkJyaWFuIENhbXBiZWxsPGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAyMCwgMjAxOCAxMDoxOCBBTTxicj4NCjxiPlRvOjwv Yj4gRmlsaXAgU2tva2FuICZsdDtwYW52YS5pcEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb T0FVVEgtV0ddIENhbGwgZm9yIGFkb3B0aW9uIGZvciAmcXVvdDtSZXNvdXJjZSBJbmRpY2F0b3Jz IGZvciBPQXV0aCAyLjAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgY3VycmVudCBkcmFmdCBkb2VzIGFsbG93IG11bHRpcGxlICZxdW90O3Jlc291cmNlJnF1 b3Q7IHBhcmFtZXRlcnMuIEhvd2V2ZXIsIHRoZXJlIHNlZW1lZCB0byBiZSBjb25zZW5zdXMgaW4g dGhlIFdHIG1lZXRpbmcgeWVzdGVyZGF5IHRoYXQgb25seSBhIHNpbmdsZSAmcXVvdDtyZXNvdXJj ZSZxdW90OyBwYXJhbWV0ZXIgd2FzIHByZWZlcmFibGUgYW5kIHRoYXQgYSBjbGllbnQgY291bGQg b2J0YWluIGFuIGFjY2VzcyB0b2tlbiBwZXIgcmVzb3VyY2UNCiAobGlrZWx5IHVzaW5nIGEgcmVm cmVzaCB0b2tlbikuIEknbSBwZXJzb25hbGx5IHN5bXBhdGhldGljIHRvIHRoYXQgcG9pbnQuIEJ1 dCBtYXliZSBpdCdzIHRvbyByZXN0cmljdGl2ZS4gSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIG1v cmUgdGV4dCBhYm91dCB0aGUgY29tcGxleGl0eSBpbXBsaWNhdGlvbnMgb2YgbXVsdGlwbGUgJnF1 b3Q7cmVzb3VyY2UmcXVvdDsgcGFyYW1ldGVycyBhbmQgcGVyaGFwcyBzb21lIGRpc2NvdXJhZ2Vt ZW50IG9mIGRvaW5nIHNvLiBJDQogYmVsaWV2ZSBsb2dpY2FsIG5hbWVzIGFyZSBtb3JlIHBvdGVu dGlhbGx5IHVzZWZ1bCBpbiBhbiBTVFMgZnJhbWV3b3JrIGxpa2UgdG9rZW4mbmJzcDtleGNoYW5n ZSBidXQgc2hvdWxkIGJlIG91dCBvZiBzY29wZSBmb3IgdGhpcyB3b3JrLiAmbmJzcDsNCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBGcmksIEp1bCAyMCwgMjAxOCBhdCAzOjQzIEFNLCBGaWxpcCBTa29rYW4gJmx0Ozxh IGhyZWY9Im1haWx0bzpwYW52YS5pcEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5wYW52YS5p cEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFRvcnN0ZW4sPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDtNdWx0 aXBsZSAmcXVvdDtyZXNvdXJjZSZxdW90OyBwYXJhbWV0ZXJzIG1heSBiZSB1c2VkIHRvIGluZGlj YXRlIHRoYXQgdGhlIGlzc3VlZCB0b2tlbiBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIGF0IG11bHRp cGxlIHJlc291cmNlIHNlcnZlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQncyBhbHJlYWR5IGluLiBGdXJ0aGVybW9yZSB3aGF0IGFi b3V0IGxvZ2ljYWwgbmFtZXMgZm9yIHRhcmdldCBzZXJ2aWNlcz8gTGlrZSB3YXMgYWRkZWQgaW4g LTAzIG9mIHRva2VuIGV4Y2hhbmdlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8YnI+DQo8Yj5GaWxpcCBTa29rYW48L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEZyaSwgSnVsIDIwLCAyMDE4IGF0IDk6MzMgQU0gVG9yc3RlbiBMb2RkZXJzdGVkdCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFu ayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbGlrZSB0byBwb2ludCBv dXQgKGFnYWluKSBhIHNpbmdsZSByZXNvdXJjZSBpcyBub3Qgc3VmZmljaWVudCBmb3IgbW9zdCB1 c2UgY2FzZXMgSSBpbXBsZW1lbnRlZCBpbiB0aGUgbGFzdCBjb3VwbGUgaWYgeWVhcnMuIEnigJht IGFkdm9jYXRpbmcgZm9yIGVuaGFuY2luZyB0aGUgZHJhZnQgdG8gc3VwcG9ydCBtdWx0aXBsZSBy ZXNvdXJjZXMgYW5kIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiB0aGUgcmVsYXRpb25zaGlwDQogYmV0 d2VlbiByZXNvdXJjZShzKSBhbmQgc2NvcGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N CkFtIDIwLjA3LjIwMTggdW0gMDg6MjAgc2NocmllYiBuLXNha2ltdXJhICZsdDs8YSBocmVmPSJt YWlsdG86bi1zYWtpbXVyYUBucmkuY28uanAiIHRhcmdldD0iX2JsYW5rIj5uLXNha2ltdXJhQG5y aS5jby5qcDwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+JiM0MzsxDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2Vu dDo8L2I+IEZyaWRheSwgSnVseSAyMCwgMjAxOCA3OjQyIEFNPGJyPg0KPGI+VG86PC9iPiBSaWZh YXQgU2hla2gtWXVzZWYgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5yaWZhYXQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNj OjwvYj4gb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtP QVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb24gZm9yICZxdW90O1Jlc291cmNlIEluZGljYXRvcnMg Zm9yIE9BdXRoIDIuMCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg c3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBKdWwgMTksIDIwMTggYXQgNDow MSBQTSwgUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5IaSBhbGwsPGJyPg0KPGJyPg0KVGhpcyBpcyB0aGUgY2FsbCBm b3IgYWRvcHRpb24gb2YgdGhlICdSZXNvdXJjZSBJbmRpY2F0b3JzIGZvciBPQXV0aCAyLjAnIGRv Y3VtZW50PGJyPg0KZm9sbG93aW5nIHRoZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlvbiBhdCB0 aGUgTW9udHJlYWwgSUVURiBtZWV0aW5nLjxicj4NCjxicj4NCkhlcmUgaXMgdGhlIGRvY3VtZW50 Ojxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Y2FtcGJlbGwtb2F1dGgtcmVzb3VyY2UtaW5kaWNhdG9ycy0wMiIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxMTU1Q0MiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC1yZXNvdXJjZS1pbmRpY2F0b3JzLTAy PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGJyPg0KPGJyPg0KUGxl YXNlIGxldCB1cyBrbm93IGJ5IEF1Z3VzdCAybmQgd2hldGhlciB5b3UgYWNjZXB0IC8gb2JqZWN0 IHRvIHRoZTxicj4NCmFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2lu dCBmb3Igd29yayBpbiB0aGUgT0F1dGg8YnI+DQp3b3JraW5nIGdyb3VwLjxicj4NCjxicj4NClJl Z2FyZHMsPGJyPg0KUmlmYWF0PC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pjxicj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3 aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlz IGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBm b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQogQW55IHJldmll dywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlv biBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFp bCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlv dXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRo IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9B dXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05G SURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBh bmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQocykuDQogQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3Vy ZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkg ZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9p PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MW2PR00MB0300E556CAC7F285C11DB784F5510MW2PR00MB0300namp_-- From nobody Fri Jul 20 08:40:09 2018 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 E8C9D129385 for ; Fri, 20 Jul 2018 08:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_REMOTE_IMAGE=0.01, 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 bMoU2pHqYxTI for ; Fri, 20 Jul 2018 08:40:04 -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 BB419130DE3 for ; Fri, 20 Jul 2018 08:40:04 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6KFd4eL148992; Fri, 20 Jul 2018 15:40:00 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=TfAvZrPIiWiG0EdprdrcO4MAt/NaCuQHj2HXsq/nBKE=; b=XRCg17ttTZJnGlnjpvHxa4sS2ew8XCAuHPS3jM60uG5PxW26fypIiir0Eh9i2n+omGx4 igfq1EPIbxslWigtQIzTasx2r5JO2K5mgc71WhFR685FbUR/1k1xKhyCjDfQIG/3cVJF cNc7DOjzztWQ9vuy9pQMGIlEz25xLRCEdG8+NhkX5+OOeXofZYaczGm8OGqIPkeJxMd2 HSmrC6kFim3uTEoiW45ldYv/B79DvDxCn/UEDX+Dc/ZUYSzKvgMOQpJt1NItS5eIEJF+ Il/woBTYQn+tMszDP0btqlm/6OJFax/qiVGYDAVmRRrZCL53K67P+zyV7/5nmfLtIFN8 Vw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2k9yjxbtdy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jul 2018 15:39:59 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w6KFdwFv016709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jul 2018 15:39:59 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6KFdwJx019376; Fri, 20 Jul 2018 15:39:58 GMT Received: from [10.0.1.20] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 20 Jul 2018 08:39:58 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-4191B48D-3DBB-432F-A1AC-65B64D3A6036 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Fri, 20 Jul 2018 08:39:56 -0700 Cc: oauth Content-Transfer-Encoding: 7bit Message-Id: References: To: Rob Otto X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8959 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807200174 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 15:40:08 -0000 --Apple-Mail-4191B48D-3DBB-432F-A1AC-65B64D3A6036 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 adoption I have always been concerned about clients doing introspection. Use of jwt h= elps because responses further restricted rather than less (jwe).=20 Phil > On Jul 20, 2018, at 7:25 AM, Rob Otto wrote: >=20 > I support this as well=20 >=20 >> On Fri, 20 Jul 2018 at 15:22, Brian Campbell wrote: >> +1=20 >>=20 >>> On Thu, Jul 19, 2018 at 1:51 PM, William Denniss wrote: >>> I support adoption of this document by the working group. >>>=20 >>>=20 >>>> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef wrote: >>>> Hi all, >>>>=20 >>>> This is the call for adoption of the 'JWT Response for OAuth Token Intr= ospection' document following the presentation by Torsten at the Montreal IE= TF meeting where we didn't have a chance to do a call for adoption in the me= eting itself. >>>>=20 >>>> Here is presentation by Torsten: >>>> https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-ses= sa-jwt-response-for-oauth-token-introspection-00 >>>>=20 >>>> Here is the document: >>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-r= esponse-01 >>>>=20 >>>> Please let us know by August 2nd whether you accept / object to the ado= ption of this document as a starting point for work in the OAuth working gro= up. >>>>=20 >>>> Regards, >>>> Hannes & Rifaat >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=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 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 >=20 >=20 > --=20 > =09 > Rob Otto=09 > EMEA Field CTO/Solutions Architect = =09 > robertotto@pingidentity.com=09 > =09 > c: +44 (0) 777 135 6092 > Connect with us: =20 >=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 rec= eived 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. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4191B48D-3DBB-432F-A1AC-65B64D3A6036 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 adoption

I have alway= s been concerned about clients doing introspection. Use of jwt helps because= responses further restricted rather than less (jwe). 

Phil

On Jul 20, 2018, at 7:25 AM, Rob Ott= o <robotto= =3D40pingidentity.com@dmarc.ietf.org> wrote:

I support this as well 

On Fri, 20 Jul 2018 a= t 15:22, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex">
+1

On Thu, Jul 19, 2018 at 1:51 PM, William D= enniss <wdenniss=3D40google.com@dmarc.ietf.org><= /span> wrote:
I support ad= option of this document by the working group.


On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi all,

This is the call for adoption of the= 'JWT Response for OAuth Token Introspection' document following the present= ation by Torsten at the Montreal IETF meeting where we didn't have a chance t= o do a call for adoption in the meeting itself.

Her= e is presentation by Torsten:

Here is the document:

Please let us k= now by August 2nd whether you accept / object to the adoption of this docume= nt as a starting point for work in the OAuth working group.

Regards,
Hannes & Rifaat

_______________________________________________
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 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


--
3D"Ping =
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= you have received this communication in error, please notify the sender imm= ediately by e-mail and delete the message and any file attachments from your= computer. Thank you.
_______________________________________________
= OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-4191B48D-3DBB-432F-A1AC-65B64D3A6036-- From nobody Fri Jul 20 08:47:42 2018 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 991541310C1 for ; Fri, 20 Jul 2018 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 sYKKBG-DBr34 for ; Fri, 20 Jul 2018 08:47:36 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 28D5B130E02 for ; Fri, 20 Jul 2018 08:47:35 -0700 (PDT) Received: from speedyM.local ([IPv6:2a02:a446:bd2c:1:70ff:cc25:1c6c:726a]) by smtp-cloud8.xs4all.net with ESMTPA id gXcwfupAmoj71gXcyfBG2H; Fri, 20 Jul 2018 17:47:34 +0200 To: Phil Hunt , Rob Otto Cc: oauth References: From: Mark Dobrinic Openpgp: preference=signencrypt Autocrypt: addr=mdobrinic@cozmanova.com; prefer-encrypt=mutual; keydata= xsFNBFnEuoUBEADAZzzoEAf+nZ7T/UPgTXTgQOxfC8Htnkn07pJ84ee4z1qtF+xSHXJPhXJj g6VhJC5+GqP0yXuAIDx0nqLHoyrydvR+2KRNs9OBAejBMdqum7bX8Ql84jj5UvMzJSrQFSr8 15i2g2tVR2+wVSQI9RwvbsAGWChQfOigjwZiICHd90r9EaM/SpWHkyLYvIJwvbOD726jmRAU /FUu4CX06PYK1A5NkWrjD3Y7+fvPgrV5DjgQci/W+WgVkrIJdW3PHlkBW81u43WTBBAhEWLa RkoYr/Kvt5y+KTP6oGVppvJ9B58oa3W2W6BhGHSa5vIlFQC+zRzUO5iiTNDmwGsrNBR9wcKc E7OopYBlgstz/fJW4+XAwJSUGaN/tTkc1XFuBw4bzTYwTTYLk8ur0+LNSTKP0Hi5LJ5iwS44 oAqplJGUBqMRQtcWKLGW1By/t6kWV9rf+NdCn9FaN+MRmWEtU5/KDYQspSXWbdPPbhE/somV vk7txHS1Q5Pfe8RyAIJ5W6YblhfD9nm7s+o/qIVjLmlZHMeB7f2bqa0GpQMGZswLCiGTlNa+ dCQwMqBaXWCtE5JB9qgnb1+HhJSPhevb4NAqy+Bpx/DUUXsUCyVHbB4ZJT83BzEuiVaJBXuV 4aYATmeQ3vSOHQhdgSbvjaYOhpcUekjCLV/0xFPkSGk37ThQtwARAQABzSdNYXJrIERvYnJp bmljIDxtZG9icmluaWNAY296bWFub3ZhLmNvbT7CwZQEEwEIAD4WIQQWQdwtTBz/Q2zpHSvZ X2lHE9zaFgUCWcS6hQIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDZX2lH E9zaFpTHD/9jwrgTBrGGRAnOtQ3p1lBiJI2vZfqKi6ZqNtggMMmM3RifMQbxCFrII3QjyTDB ZxHTLQWctBMCbA3F8VvUjvSqH444sBDGv2TVyILIjMSqKXoiKNhSYcEvUTOOfU87ouuNW0F/ tRg7irhypHUXUyZbF04gbdmWfQwllVinaoR30meO9Vk1gthFpbNsjqnXpLbPzacSVYwQJxc6 8xaW5djbOXAVwgVMq27p/IN7lYva8S2/WC81BvjGNF4pohHDu3DIdYhtQAh+PKRbTsZErlk0 GcVoTSs71l5A9QC7JgVK5MagzHcCzGDqtDZFfOfXFFpSi6obF0/W1XDNSz3TPlJyJMvn0N1V BS/TRAzGO59apiagcd5Z4nCcheOAFhPELclW7dggtCG5bCTU1G/+mMOVo7HZaD9LI0/ETqdv 8UZetXNSDR93UlUqEBUBHY73FL4ZqIsM+4I01IgMidumB2yBieMonONYabAKw3/x7J74CejL 7FglultGVpRoI8BUEtT5Kc7zZi3kxCNArLTiS0M1MTJKaNNY3qsIZy/N1Y3sdAOSuPKo8178 bzNKO9or14LTKV9RpyGDLu5XLf1OMdcESIOL2gfyaMlRtrjjtqL1EyTWYWOYuyRx8YIMUkPq RhFnwmgCsIqJ9waAukM6h5aTmBvsidQeOKMimBjF1Cqx1s7BTQRZxLqFARAAuo3PVWUs1jih vsQnx7FxJaXWc3EGxYq5JT1bzhXdnEMbD7E9UIRIrV1fh2GQVacx+jmfe+zC53ADMSLPxkGb 7E/MliQN07B4BCfk1yHEmNioo8FBfEj2KKcKgFIBp13ELzCsEL2kyWN+OvHNXWftfUXcUXuH m2veI5KyFTXz2m4xk/MxsPvTqf86MeugnmamiNoH1N5VLeX/UlXv3y2gm3pAeb0999tFnVIq TjwwQEAMvS4e1tZC/YsfB2epA49f+zDsTIBykmWfqdKDABzElIbZoSOHoqJIfIDsTgJnmJhw /Xi8TydKWtf2rmDaldcMgPv7mGmVgglGjdDEHk4gd79VcVXNP/0KfP2uEfubZrqJmKgYQDJZ 8CwWgpRaIy2SlUNqMsyh2x284R3FtUoL08PdP48MIGPX+bBbOorM+mJ68EoNcy9eJbRP/MBH 2qHJpSaq2CTS8z8PlTaZKhEq7MJiTirrxzr6k+uk03G5i271mUcpGZlCCwWJQisvfoFOwEqc UEi9pXW3tA6D9yagq6dPgy0OwheAEeNwiFduk1H5EtKLWuWHo+fcgjWdmv4+oF5icdY6EfYh 7yovI8sn5gJU9oDRRMoVG0UpeHxxO2XCmOa7TP8wm4C6xUxIssYGe5FRXX1weCTWUhJYQiS+ KHQwhR7DwK+TkguOfwXWxTkAEQEAAcLBfAQYAQgAJhYhBBZB3C1MHP9DbOkdK9lfaUcT3NoW BQJZxLqFAhsMBQkJZgGAAAoJENlfaUcT3NoW9/oQAIAI6SBsVZYS6gKxctZ1/pVuakj3GiDn LVNT+iAgaXyyRF8VorW1xJLHq07ZPubzYy/TqkMlwqdOlVQtFg+fwRuOSF7Gqt8Qsay0rU6Y tS7y7zojhcqtIRQA1MrhCPUMv3itKXt4pt0Ky3syoRRmiudFLhUdEcNB0aWb1udRf0kI4408 dpcZXcgbkoQe4ZN4P8SuUFSHpySUAEyZdXceQtehsdN43oApQBDnj5JDeBelbWnduZ4kBOax /3CWrG3CTOrrhwuiJx/VXAbq388U3aN6rurCKb/UAX81yZHVjZ5wiUkTjGdfXZFf+9rO5Dck M+jsVgB92jXPDaGxBRqVpRQlalgjUVEzEy5uevLp6sEjP4gFeHvSo9QwiIqgnRIANKfqf+au DSoeIHDazbHfYMmeIr4bEz3pCcT7pFliG+E5QnUfHUu/Bw55VCU4+9Yw9nmPkXI/RZOJRbTS O1DysaP/GF3U9rgO/st67YgZDUYO7L/d5eYHuCC9ukVOM3ALgjWryIHWV2knvV7dfgVPz3r+ zF9t3uK37cE38vgv0bdoZ+NBZwXF4+CK2wGN3wCErUz7vOnoBR1Osph4nm/qwXlXv6mxY3XK mUNYwLxQn7Lfau0t+6/SsC/6va13rSOc43vXI/Cqtkzwzkysg/phmZDr8HLpaboGOWZkWPUF 4I+B Message-ID: <670e70fd-d494-9153-9b41-5cab0eab0dd0@cozmanova.com> Date: Fri, 20 Jul 2018 17:47:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfNE0d0t1Y6PgeajyKkE8H/NrXGrccuIp/J0MSXUu56TxaPaJ592XTIXjrzJXrkfnFMjRwaan/W5uIfKE1frcTntBoRSOm+AyWt06nrFF+FcCPwUgSIMl M0hGCXS9kMsKH067uJe/Kbk7n0mpCYJEwOAIxsKfYcjujCG87V9po7th6mzlQpKD8FQenSaDFYX0RpUT5+0S7ZUlZ5R1Sv/kgHYH+0CJD1mEqAx25nywGcnq F3ibUoLPvdO/YXDaW2FSc1Ew1NXCNKBCe3otG4lENl8Fcn9rFB9aZHhhKR5xFCNNOmhd9Y7apPD7otjG+hfJFA== Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 15:47:41 -0000 I +1 this, but at the same time, I'm wondering what happened with the argument that this should be solved by Token Exchange instead of Introspect? Cheers! Mark On 20/07/18 17:39, Phil Hunt wrote: > +1 adoption > > I have always been concerned about clients doing introspection. Use of > jwt helps because responses further restricted rather than less (jwe).  > > Phil > > On Jul 20, 2018, at 7:25 AM, Rob Otto > > wrote: > >> I support this as well  >> >> On Fri, 20 Jul 2018 at 15:22, Brian Campbell >> > > wrote: >> >> +1 >> >> On Thu, Jul 19, 2018 at 1:51 PM, William Denniss >> > > wrote: >> >> I support adoption of this document by the working group. >> >> >> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef >> > wrote: >> >> Hi all, >> >> This is the call for adoption of the 'JWT Response for >> OAuth Token Introspection' document following the >> presentation by Torsten at the Montreal IETF meeting where >> we didn't have a chance to do a call for adoption in the >> meeting itself. >> >> Here is presentation by Torsten: >> https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00 >> >> Here is the document: >> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01 >> >> Please let us know by August 2nd whether you accept / >> object to the adoption of this document as a starting >> point for work in the OAuth working group. >> >> Regards, >> Hannes & Rifaat >> >> _______________________________________________ >> 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 >> >> >> >> -- >> Ping Identity >> >> Rob Otto >> EMEA Field CTO/Solutions Architect >> robertotto@pingidentity.com >> >> c: +44 (0) 777 135 6092 >> >> Connect with us: Glassdoor logo >> >> LinkedIn logo twitter logo >> facebook logo >> youtube logo >> Google+ logo >> Blog logo >> >> >> >> >> /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 > From nobody Fri Jul 20 10:37:38 2018 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 9C4CE130DEE; Fri, 20 Jul 2018 10:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 D4sEOPKC4ESE; Fri, 20 Jul 2018 10:37:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 714BF130F74; Fri, 20 Jul 2018 10:37:21 -0700 (PDT) Received: from dhcp-84b0.meeting.ietf.org (dhcp-84b0.meeting.ietf.org [31.133.132.176]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6KHbIKh017114 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 20 Jul 2018 12:37:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks To: gen-art@ietf.org Cc: draft-ietf-oauth-device-flow.all@ietf.org, ietf@ietf.org, oauth@ietf.org References: <152873404689.2672.12557627140070509936@ietfa.amsl.com> Message-ID: Date: Fri, 20 Jul 2018 13:37:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <152873404689.2672.12557627140070509936@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] [Gen-art] Genart last call review of draft-ietf-oauth-device-flow-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 17:37:27 -0000 As far as I can tell, there has been no response to this. The document revision just updated a reference to reflect an rfc having been published. Apologies if I missed a response. RjS On 6/11/18 12:20 PM, Robert Sparks wrote: > Reviewer: Robert Sparks > Review result: Ready with Nits > > 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-device-flow-10 > Reviewer: Robert Sparks > Review Date: 2018-06-11 > IETF LC End Date: 2018-06-12 > IESG Telechat date: Not scheduled for a telechat > > Summary: Ready for publication as a Proposed Standard RFC, but with nits to > consider > > Nits/editorial comments: > > In 3.5 "the client MUST use a reasonable default polling interval" is not > testable. Who determines "reasonable"? At the very least, you should add some > text about how to determine what "reasonable" is for a given device, and add > some text that says don't poll faster than earlier responses limited you to. > For example, if the response at step B in the introductory diagram had an > explicit interval of 15, but a slow-down response to an E message didn't have > an explicit interval, you don't want them to default to, say 5 seconds (because > that's what the example in section 3.2 said, so it must be reasonable). > > In 3.3, you say the device_code MUST NOT be displayed or communicated. Is there > a security property that's lost if there is? Or is this just saying "Don't > waste space or the user's time"? > > The last paragraph of section 6.1 feels like a recipe for false positives, and > for bug-entrenched code. Please reconsider it. > > You need line-folding in the example in section 3.2 > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Fri Jul 20 10:46:43 2018 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 8103C1310A6 for ; Fri, 20 Jul 2018 10:46:42 -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 9AIYmhFCsQvI for ; Fri, 20 Jul 2018 10:46:39 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 C0C89130F17 for ; Fri, 20 Jul 2018 10:46:39 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id r1-v6so7461947pgp.11 for ; Fri, 20 Jul 2018 10:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zawHkHOWgc39wxQlZVFgNDF3fZtGJJDEBn1gCNhXCQE=; b=dNBrrdnSTbXihYLxkF1qks02rtJHu844jRm71CAy3rGLt1h/B3vj0C+oIISbE+Q5/j GzxgGgVJZu8bRpVKvFpBJdswD4uHndbN4cWDRz2Vi65QHyuW96F2p2bg5f/Zd7VlRvx/ 06kHJbe2s5BvMqvIUVpc6bKsmsqNPGMi07k4+ELy+sTMDa5xLPM+GlA8cLK7lty7HZTW GJeBEIbafgaygxx4IeaP3fOkTyFE+ramQe/JjYRuL6XWRrqVOnhQ7sNklUpBF3MWwMbn PpjXg8b+WVp9g+NjPILgfNlNyWPBYmMvAx2QVGIB+0u93z1IMJ58/LZ9GvRR3Hhtv3Fb YXhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zawHkHOWgc39wxQlZVFgNDF3fZtGJJDEBn1gCNhXCQE=; b=tfADq2eUsm8vuCQztLu/taDdn8fJOPAKaU8+QxKxgKUG//fnMVpMiicFuIiBpcYEfn KcPxNFi31JVoozFUC2J59XQ5mS8cexazChAVvoLjCD55O3EX8nZCQBdBWL/DdUYehmwi XZpylqB18yHSq3TrtOoOZg/FPteX8R2ld6n2pPIn54eTrqGqwGFmM35mx15bzLSlJh7b FehrDA3B948wFhwvCLJEVmpZu3MnsLkud2cv+ZWZh/+AI/Ein7ZPMVplq3K4RHsohZr9 wImyH4+67vIKHP3/f3Dec6dkTHRxdBwswNYZQb1ITGQi39l4Fl0pj03EjUP2Qz5t3oIm fk0g== X-Gm-Message-State: AOUpUlHwJxS/LozO38Yaj0yiaSSo4nvahpe5ZgvyVDNC3x34z2/aRJky al2omuoEnOy495Amgyl5JswkgAyzJuDDMuXwsMk= X-Google-Smtp-Source: AAOMgpcgyZdl1cMVR7WBuVYIzi8h452idBlE9UdFN0PSza2KyUBMGvP+jtRRHnm0SLAqzdLwVB9gYGPS5FxyMSHWWNw= X-Received: by 2002:aa7:84c2:: with SMTP id x2-v6mr3110817pfn.220.1532108799141; Fri, 20 Jul 2018 10:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Fri, 20 Jul 2018 10:46:18 -0700 (PDT) In-Reply-To: References: <426DBA0B-CC9B-4D9D-9ED8-5AD779159638@lodderstedt.net> From: Dick Hardt Date: Fri, 20 Jul 2018 13:46:18 -0400 Message-ID: To: Mike Jones Cc: Brian Campbell , Filip Skokan , oauth Content-Type: multipart/alternative; boundary="000000000000baebf7057171e054" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 17:46:43 -0000 --000000000000baebf7057171e054 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are a few places where multiple resources could be used: One is in the code flow where it is desirable to optimize the user experience so that the user is granting authorization once, and not multiple times. The second is in the access token request, which leads to the third instance, which is in the access token. If an access token is being returned for each resource, then making a single request is simpler, it seems to complicate the interface more. If we want to have audience constrained access tokens, then it is safer to have only one resource in the access token - otherwise each resource can use the access token to access the other resources. All of these examples assume that it is a single AS. Supporting multiple AS in a single request seems super complicated and wrought with security and trust issues. On Fri, Jul 20, 2018 at 11:13 AM, Mike Jones < Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > While I agree that a single requested resource is the common case, enough > people have spoken up with a need for multiple requested resources over t= he > years that I think everyone will be better served by leaving the ability = to > specify multiple requested resources in the specification. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * Brian Campbell > *Sent:* Friday, July 20, 2018 10:18 AM > *To:* Filip Skokan > > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for > OAuth 2.0" > > > > The current draft does allow multiple "resource" parameters. However, > there seemed to be consensus in the WG meeting yesterday that only a sing= le > "resource" parameter was preferable and that a client could obtain an > access token per resource (likely using a refresh token). I'm personally > sympathetic to that point. But maybe it's too restrictive. I would like t= o > see some more text about the complexity implications of multiple "resourc= e" > parameters and perhaps some discouragement of doing so. I believe logical > names are more potentially useful in an STS framework like token exchange > but should be out of scope for this work. > > > > > > > > > > > > > > > > On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan wrote: > > Hi Torsten, > > > > > Multiple "resource" parameters may be used to indicate that the issued > token is intended to be used at multiple resource servers. > > > > That's already in. Furthermore what about logical names for target > services? Like was added in -03 of token exchange? > > > Best, > *Filip Skokan* > > > > > > On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > I support adoption of this document. > > > > I would like to point out (again) a single resource is not sufficient for > most use cases I implemented in the last couple if years. I=E2=80=98m adv= ocating > for enhancing the draft to support multiple resources and a clear > definition of the relationship between resource(s) and scope. > > > Am 20.07.2018 um 08:20 schrieb n-sakimura : > > +1 > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Brian Campbell > *Sent:* Friday, July 20, 2018 7:42 AM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for > OAuth 2.0" > > > > I support adoption of this document. > > > > On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef > wrote: > > Hi all, > > This is the call for adoption of the 'Resource Indicators for OAuth 2.0' > document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: > https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 > > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Regards, > Rifaat > > > _______________________________________________ > 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 > > _______________________________________________ > 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 > > --000000000000baebf7057171e054 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are a few places where multiple resources could be u= sed:

One is in the code flow where it is desirable to op= timize the user experience so that the user is granting authorization once,= and not multiple times.=C2=A0

The second is in th= e access token request, which leads to the third instance, which is in the = access token. If an access token is being returned for each resource, then = making a single request is simpler, it seems to complicate the interface mo= re.

If we want to have audience constrained access= tokens, then it is safer to have only one resource in the access token - o= therwise each resource can use the access token to access the other resourc= es.

All of these examples assume that it is a sing= le AS. Supporting multiple AS in a single request seems super complicated a= nd wrought with security and trust issues.




On Fri, Jul 20, 2018 at 11:13 AM, Mike Jones <<= a href=3D"mailto:Michael.Jones=3D40microsoft.com@dmarc.ietf.org" target=3D"= _blank">Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote= :

While I agree that a s= ingle requested resource is the common case, enough people have spoken up w= ith a need for multiple requested resources over the years that I think eve= ryone will be better served by leaving the ability to specify multiple requested resources in the specification.<= u>

=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=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=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 -- Mike

=C2=A0

From: OAuth <oauth-bounces@ietf.org> On Behalf = Of Brian Campbell
Sent: Friday, July 20, 2018 10:18 AM
To: Filip Skokan <panva.ip@gmail.com>


Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicat= ors for OAuth 2.0"

=C2=A0

The current draft does allow multiple "resource= " parameters. However, there seemed to be consensus in the WG meeting = yesterday that only a single "resource" parameter was preferable = and that a client could obtain an access token per resource (likely using a refresh token). I'm personally sympathetic to that poi= nt. But maybe it's too restrictive. I would like to see some more text = about the complexity implications of multiple "resource" paramete= rs and perhaps some discouragement of doing so. I believe logical names are more potentially useful in an STS framework like= token=C2=A0exchange but should be out of scope for this work. =C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan <panva.ip@gmail.com> wrote:

Hi Torsten,

=C2=A0

>=C2=A0Multiple "resource" parameters m= ay be used to indicate that the issued token is intended to be used at mult= iple resource servers.

=C2=A0

That's already in. Furthermore what about logica= l names for target services? Like was added in -03 of token exchange?


Best,
Filip Skokan

=C2=A0

=C2=A0

On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

I support adoption of this document.

=C2=A0

I would like to point out (again) a single resource = is not sufficient for most use cases I implemented in the last couple if ye= ars. I=E2=80=98m advocating for enhancing the draft to support multiple res= ources and a clear definition of the relationship between resource(s) and scope.


Am 20.07.2018 um 08:20 schrieb n-sakimura <n-sakimura@nri.co.jp>:

+1

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicat= ors for OAuth 2.0"

=C2=A0

I support adoption of this document.

=C2=A0

On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef = <rifaat.ietf@= gmail.com> wrote:

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-i= ndicators-02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat


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

=C2=A0


CONFIDENTIAL= ITY 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..=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 attach= ments from your computer. Thank you.

_______________________________________________=
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
h= ttps://www.ietf.org/mailman/listinfo/oauth

=C2=A0


CONFIDENTIAL= ITY 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..=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 attach= ments from your computer. Thank you.


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


--000000000000baebf7057171e054-- From nobody Fri Jul 20 10:47:12 2018 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 7F0C213121B; Fri, 20 Jul 2018 10:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 hsgVMPQCZOXe; Fri, 20 Jul 2018 10:46:52 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70088.outbound.protection.outlook.com [40.107.7.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A0B131206; Fri, 20 Jul 2018 10:46:51 -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=Kb3BmnW2S+UYOPzj0ibtUfOR+/bvpi+KXZKsXC5cAZc=; b=FCMYLzsJOXkV0kV5v/DU+Io2ivFaukStz1ynyEB19mvMPI+sesdgGywZvOjvutSzx+BHmFhBk67iHnlRvQ8QIwRs1NiZwle+2P3ycvIu5oklyA+eC7NTQ+4thkN7YeDsS+9rEBWUgnj0K0ZDyRQBOJp+AFsPbBDOIwFeg6vUX0w= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2734.eurprd08.prod.outlook.com (10.166.198.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Fri, 20 Jul 2018 17:46:47 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%10]) with mapi id 15.20.0952.021; Fri, 20 Jul 2018 17:46:47 +0000 From: Hannes Tschofenig To: oauth , "ace@ietf.org" Thread-Topic: Progressing the HTTP parameter encoding for OAuth PoP Key Distribution Thread-Index: AdQgUXSupVvWyMaDROO8wlEEZAEOPA== Date: Fri, 20 Jul 2018 17:46:47 +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: [31.133.157.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2734; 6:Y2AZyeokipQ4BNAGspOu9ex3njbPBb60KUFjuKybxcK8lCGDVtv1KnGp91yOW6Ff0ERARKfAdS1NGRF3Xgd7P0YLHwXwm7PN1TvOYFYlXKkffdkwP2CPOf3pCHSnKSEDK0adcGkTcqY0Hfr2cm9gXHV5nw+rSBNjQhSjE35RhIMYagLM/mtKk+MVOTkSrMN4+gyZhcFVGAxFp162vFoEeYlJVySxwb4Eu9HzxYD8fIZNaY6XE4V2uY2+FKMdJUhgoBPligcr3PM3upWsrSNDzHVYDn9Is+89SbmxNrAq/dfpXC+Na01/WE3bp4BM8abvtjGUcUeiIjGdBdQ8EFVjVg2tTwbkDre4r+ImL/QiTBDTZbBgafG1964bKLt/4yxis3/qn0j8DeVveUV7qn1vBfYwNztps//SYHzIN6EL5p/GW9dggwVdlsLfCC9ZvVJE5ZbtbyBC7x1UDYeEkxUH8w==; 5:bDZjFNakF53FhOJGQr/SlqdC0H9u0v3vGuagh0iXUWqLJ4FE5Wa2PC2ahOzQP0PBmyZOiyKc1G5Xj5tDIdQuHuG8wFA0DBHZaRW4xMuNZmZ0ZnpICb51fuDZODk5mnoDPrfdflffrIs6tndIqAqNKjq7xQ1tP7iD3KUFpDbzrxY=; 7:QCJdpE/83F5k2/vE5lEAwxssC2QxPn5uBBLIferzNd4Tsi3+pXtdfMMtQ8YvKatqjn+EEUnIp9K3V7DeUA59EZgPWv17owlaUfKUnHMLZetp6QWNzt6K88xyw+HT2n1eYvEEjQntcdsU1OQesgU4YqFPlF/JLYF6gSJsj4ZxhCIHoqWJUOOfSnQWheDH2b63m0e+T/2RPcVf2652mJg/pkSeObIUZGXaaWdMYta0UL0lnrGFx0NI0AbYqK+fylsZ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1380c09d-9c89-4c97-2908-08d5ee68c434 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2734; x-ms-traffictypediagnostic: VI1PR0801MB2734: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(223705240517415)(788757137089)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB2734; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2734; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(396003)(136003)(346002)(189003)(199004)(40434004)(53754006)(790700001)(256004)(5024004)(14444005)(26005)(81156014)(3846002)(81166006)(8676002)(6506007)(2501003)(25786009)(6116002)(450100002)(8936002)(5250100002)(102836004)(33656002)(105586002)(106356001)(486006)(2906002)(53936002)(561944003)(66066001)(74316002)(476003)(186003)(2900100001)(7736002)(316002)(5660300001)(68736007)(110136005)(14454004)(97736004)(9686003)(55016002)(99286004)(54896002)(478600001)(6306002)(6436002)(72206003)(7696005)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2734; 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-microsoft-antispam-message-info: 70uBVtYLMiDU437B6u9Y8yZn6rPiWd3qFt5DxeX9BsTf271qp9aghas84kmrzf4Jq7VslG9+dxxzNRCpQta6nDKvpu8F1MniEO8kYWaJRskc6uCJctBIs31GYaaUifzx7b4L7gvMQfezGiXjvtibFhx9krjUwCl3Q4+8ei4ZnrC8oPaes0sk2pxew7e+6c2VG+LvMY+tuFi1YyKqaxMpyTOsGQhnT8CMytv1eHsC6tiRimV+l8Z4WmWggx/w3fFzQV7YMKPFa0A8jKL7tahlsY8iTEhJ3SM6l2QqnGTOHhEboUWDjNPIl2YKSwbMAVbkRQ18Fejsd2A2FF/I/X3QGOJYh+iP9zCJv5p0i9vxlCQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21120EA478D0783F9FCDDC0DFA510VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1380c09d-9c89-4c97-2908-08d5ee68c434 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 17:46:47.7594 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2734 Archived-At: Subject: [OAUTH-WG] Progressing the HTTP parameter encoding for OAuth PoP Key Distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 17:47:06 -0000 --_000_VI1PR0801MB21120EA478D0783F9FCDDC0DFA510VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, after several discussions we believe that we now have a proposal for moving= forward on this topic. We plan to update the expired draft and (1) remove the audience parameter and replace it with a separately-specifie= d resource parameter, (2) remove the alg parameter, (3) update the procedures for requesting and obtaining keying material, (4) Synchronize with the ACE and WebRTC work to make sure that their use ca= ses are appropriately covered. Regarding (1): The meeting participants have decided to standardize an audi= ence-alike parameter (in the form of a requested resource identifier) at th= is weeks IETF OAuth meeting. For that purpose, working group adoption of dr= aft-campbell-oauth-resource-indicators is under way. Only a reference to t= hat document will be needed. Regarding (2): Removal of the alg parameter will simplify the document and = does not appear to be necessary for the currently investigated use cases. T= his assumption will have to be verified. Regarding (3): Currently, the ACE-OAuth document and the use different parameter names. Furthermore, those = parameter names may be in conflict with other, already standardized paramet= er names. Hence, some parameters may need to be renamed. The plan is to foc= us on the following, minimal functionality only: server-side symmetric key = generation and client-side public key registration to the AS. Furthermore, = the encoding of the key transport will have to take the different token for= mats and protocols into account. This approach will allow the ACE and WebRTC work to reference the generic P= oP key distribution document without having to specify their own duplicate = functionality. We are planning to update next w= eek to have something to review. Ciao Hannes & Rifaat 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_VI1PR0801MB21120EA478D0783F9FCDDC0DFA510VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

after several discussions we believe that we now hav= e a proposal for moving forward on this topic.

We plan to update the expired draft <draft-ietf-o= auth-pop-key-distribution-03> and

(1) remove the audience parameter and replace it wit= h a separately-specified resource parameter,

(2) remove the alg parameter,

(3) update the procedures for requesting and obtaini= ng keying material,

(4) Synchronize with the ACE and WebRTC work to make= sure that their use cases are appropriately covered.

 

Regarding (1): The meeting participants have decided= to standardize an audience-alike parameter (in the form of a requested res= ource identifier) at this weeks IETF OAuth meeting. For that purpose, worki= ng group adoption of draft-campbell-oauth-resource-indicators is under way.  Only a reference to that document will be needed. = ;

 

Regarding (2): Removal of the alg parameter will sim= plify the document and does not appear to be necessary for the currently in= vestigated use cases. This assumption will have to be verified.

 

Regarding (3): Currently, the ACE-OAuth document and= the <draft-ietf-oauth-pop-key-distribution-03> use different paramet= er names. Furthermore, those parameter names may be in conflict with other,= already standardized parameter names. Hence, some parameters may need to be renamed. The plan is to focus on the follow= ing, minimal functionality only: server-side symmetric key generation and c= lient-side public key registration to the AS. Furthermore, the encoding of = the key transport will have to take the different token formats and protocols into account.

 

This approach will allow the ACE and WebRTC work to = reference the generic PoP key distribution document without having to speci= fy their own duplicate functionality.

 

We are planning to update <draft-ietf-oauth-pop-k= ey-distribution-03> next week to have something to review.

 

Ciao

Hannes & Rifaat

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_VI1PR0801MB21120EA478D0783F9FCDDC0DFA510VI1PR0801MB2112_-- From nobody Fri Jul 20 11:29:26 2018 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 58A821310FE for ; Fri, 20 Jul 2018 11:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 oYwtgbgWSbCn for ; Fri, 20 Jul 2018 11:29:11 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4AE1310CC for ; Fri, 20 Jul 2018 11:29:11 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:f839:906b:e7ad:6493] (unknown [IPv6:2601:282:202:b210:f839:906b:e7ad:6493]) by alkaline-solutions.com (Postfix) with ESMTPSA id 51FE531544; Fri, 20 Jul 2018 18:29:10 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_98EFA94F-90B0-4D31-9030-B49AC8290744" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 20 Jul 2018 12:29:09 -0600 In-Reply-To: Cc: Dick Hardt , "oauth@ietf.org" To: n-sakimura References: <1AD25F21-4F76-41CA-96E8-6E09373D04E8@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 18:29:20 -0000 --Apple-Mail=_98EFA94F-90B0-4D31-9030-B49AC8290744 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 20, 2018, at 2:33 AM, n-sakimura wrote: >=20 > I did not quite follow why CORS is relevant here. We are just talking = about the client to server communication, and there are no embedded = resources in the response. Could you kindly elaborate a little, please?=20= Sure! It is effectively an additional (complex) restriction on = implementation/capabilities of CORS and the design of the resources. There are five possible access results for a resource that come to mind: 1. Client does not have authorization but gets a (possibly limited) = entity response 2. Client does not have authorization and is challenged 3. Client has authorization and gets a (possibly customized) entity = response 4. Client has insufficient authorization and is challenged (e.g. for a = new access token, possibly with more scopes) 5. Client has insufficient authorization and is refused access The CORS policies returned for 1 and 3 may be different than 2 and 4, = may be different for 5, and may come from different infrastructure (such = as an authenticating reverse proxy =E2=80=9Cgateway=E2=80=9D). Note also = that cases 1 and 3 may have a WWW-Authenticate header on the response, = indicating that providing authorization may return a different entity = response. One way to handle remote access for all of these cases with commonality = would be to expose the WWW-Authenticate header via the CORS policy. With the Link header used as well, you would need to also expose the = Link header in all of these cases (or at least 1-4). However, the Link = header can return many relations beyond this one authorization use case, = and you would be exposing those all-or-nothing.=20 You effectively lose the ability to regulate visibility of the Link = header via CORS, and must resort to selective disclosure of headers as = your mechanism of control (or serialize those links in another way such = as within the content body, when an available option) -DW > =20 > For the second point, since it was discussed in the WG meeting = yesterday, I will defer to that discussion. > =20 > Best,=20 > =20 > Nat Sakimura > =20 > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of David Waite > Sent: Thursday, July 19, 2018 4:55 PM > To: Dick Hardt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] updated Distributed OAuth ID > =20 > Four comments. > =20 > First: What is the rationale for including the parameters as Link = headers rather than part of the WWW-Authenticate challenge, e.g.: > =20 > WWW-Authenticate: Bearer realm=3D"example_realm", > scope=3D"example_scope", > error=3D=E2=80=9Cinvalid_token", > resource_uri=3D"https://api.example.com/resource = ", > = oauth_server_metadata_uris=3D"https://as.example.com/.well-known/oauth-aut= horization-server = = https://different-as.example.com/.well-known/oauth-authorization-server = "= > =20 >=20 > My understanding is that the RFC6750 auth-params are extensible (but = not currently part of any managed registry.) > =20 > One reason to go with this vs Link headers is CORS policy - exposing = Link headers to a remote client must be done all or nothing as part of = the CORS policy, and can=E2=80=99t be limited by the kind of link. > =20 > Second: (retaining link format) Is there a reason the metadata = location is specified the way it is? It seems like > =20 > >; = rel=3D=E2=80=9Coauth_server_metadata_uri" > =20 > should be > =20 > >; = rel=3D=E2=80=9Coauth_issuer" > =20 > OAuth defines the location of metadata under the .well-known endpoint = as a MUST. An extension of OAuth may choose from at least three = different methods for handling extensions beyond this: > 1. Add additional keys to the oauth-authorization-server metadata > 2. Add additional resources to .well-known for clients to supporting = their extensions to attempt to resolve, treating =E2=80=98regular=E2=80=99= OAuth as a fallback. > 3. Define their own parameter, such as rel=3D=E2=80=9Cspecialauth_issuer= =E2=80=9D, potentially using a different mechanism for specifying = metadata > =20 > Given all this, it seems appropriate to only support specifying of = metadata-supplying issuers, not metadata uris. > =20 > Third: I have doubts of the usefulness of resource_uri in parallel to = both the client requested URI and the Authorization =E2=80=9Crealm=E2=80=9D= parameter. > =20 > As currently defined, the client would be the one enforcing (or = possibly ignoring) static policy around resource URIs - that a resource = URI is arbitrary except in that it must match the host (and = scheme/port?) of the requested URI. The information on the requested URI = by the client is not shared between the client and AS for it to do its = own policy verification. It would seem better to send the client origin = to the AS for it to do (potential) policy verification, rather than = relying on clients to implement it for them based on static spec policy. > =20 > The name =E2=80=9Cresource URI=E2=80=9D is also confusing, as I would = expect it to be the URI that was requested by the client. The purpose of = this parameter is a bit confusing, as it is only defined as =E2=80=9CAn = OAuth 2.0 Resource Endpoint specified in [RFC6750] section 3.2 - where = the term doesn=E2=80=99t appear in 6750 and there does not appear to be = a section 3.2 ;-) > =20 > It seems that: > a. If the resource_uri is a direct match for the URI requested for the = client, it is redundant and should be dropped > (If the resource URI is *not* a direct match with the URI of the = resource requested by the client, it might need a better name). > b. If the resource URI is meant to provide a certain arbitrary = grouping for applying tokens within the origin of the resource server, = what is its value over the preexisting =E2=80=9C realm=E2=80=9D = parameter? > c. If the resource URI is meant to provide a way for an AS to allow = resources to be independent, identified entities on a single origin - = I=E2=80=99m unsure how a client would understand it is meant to treat = these resource URIs as independent entities (e.g. be sure not to send = bearer tokens minted for resource /entity1 to /entity2, or for that = matter prevent /entity1 from requesting tokens for /entity2). > =20 > Admittedly based on not fully understanding the purpose of this = parameter, it seems to me there exists a simpler flow which better = leverages the existing Authentication mechanism of HTTP.=20 > =20 > A request would fail due to an invalid or missing token for the realm = at the origin, and and the client would make a request to the issuer = including the origin of the requested resource as a parameter. Any other = included parameters specified by the WWW-Authenticate challenge = understood by the client (such as =E2=80=9Cscope=E2=80=9D) would also be = applied to this request. > =20 > Normal authorization grant flow would then happen (as this is the only = grant type supported by RFC6750). Once the access token is acquired by = the client, the client associates that token with the =E2=80=9Crealm=E2=80= =9D parameter given in the initial challenge by the resource server = origin. Likewise, the =E2=80=98aud=E2=80=99 of the token as returned by = a token introspection process would be the origin of the resource = server. > =20 > It seems any more complicated protected resource groupings on a = resource server would need a client to understand the structure of the = resource server, and thus fetch some sort of resource server metadata. > =20 > Fourth and finally: Is the intention to eventually recommend token = binding here? Token binding as a requirement across clients, resources, = and the authorization servers would isolate tokens to only being = consumed within an origin. This would actually make = redundant/supplemental the AS additions defined within this spec = (resource/origin request parameter, =E2=80=98aud=E2=80=99 introspection = response member) > =20 > -DW >=20 >=20 > On Jun 12, 2018, at 1:28 PM, Dick Hardt > wrote: > =20 > Hey OAuth WG > =20 > I have worked with Nat and Brian to merge our concepts and those are = captured in the updated draft. > =20 > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ = > =20 > We are hopeful the WG will adopt this draft as a WG document. > =20 > Any comments and feedback are welcome! > =20 > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_98EFA94F-90B0-4D31-9030-B49AC8290744 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 20, 2018, at 2:33 AM, n-sakimura <n-sakimura@nri.co.jp> wrote:

I = did not quite follow why CORS is relevant here. We are just talking = about the client to server communication, and there are no embedded = resources in the response. Could you kindly elaborate a little, = please? 

Sure!  It is = effectively an additional (complex) restriction on = implementation/capabilities of CORS and the design of the = resources.

There are five possible = access results for a resource that come to mind:
1. Client = does not have authorization but gets a (possibly limited) entity = response
2. Client does not have authorization and is = challenged
3. Client has authorization and gets a (possibly = customized) entity response
4. Client has insufficient = authorization and is challenged (e.g. for a new access token, possibly = with more scopes)
5. Client has insufficient authorization and = is refused access

The CORS policies = returned for 1 and 3 may be different than 2 and 4, may be different for = 5, and may come from different infrastructure (such as an authenticating = reverse proxy =E2=80=9Cgateway=E2=80=9D). Note also that cases 1 and 3 = may have a WWW-Authenticate header on the response, indicating that = providing authorization may return a different entity = response.

One way to handle remote = access for all of these cases with commonality would be to expose the = WWW-Authenticate header via the CORS policy.

With the Link header used as well, you would need = to also expose the Link header in all of these cases (or at least 1-4). = However, the Link header can return many relations beyond this one = authorization use case, and you would be exposing those = all-or-nothing. 

You = effectively lose the ability to regulate visibility of the Link header = via CORS, and must resort to selective disclosure of headers as your = mechanism of control (or serialize those links in another way such as = within the content body, when an available option)

-DW

 
For = the second point, since it was discussed in the WG meeting yesterday, I = will defer to that discussion.
 
Best, 
 
Nat = Sakimura
 
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of David Waite
Sent: Thursday, July 19, 2018 = 4:55 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] updated = Distributed OAuth ID
 
Four comments.
 
First: What is the rationale for = including the parameters as Link headers rather than part of the = WWW-Authenticate challenge, e.g.:
 
WWW-Authenticate: Bearer realm=3D"example_realm",
                =             =  scope=3D"example_scope",
      =                     =    error=3D=E2=80=9Cinvalid_token",
    resource_uri=3D"https://api.example.com/resource",

 

My understanding is that the RFC6750 = auth-params are extensible (but not currently part of any managed = registry.)
 
One reason to go with this vs Link headers is CORS policy - = exposing Link headers to a remote client must be done all or nothing as = part of the CORS policy, and can=E2=80=99t be limited by the kind of = link.
 
Second: (retaining link format) Is there a reason the = metadata location is specified the way it is? It seems like
 
<https://as.example.com/.well-known/oauth-authorization-server>; rel=3D=E2=80=9Coauth_server_metadata_uri"
should be
<https://as.example.com>; = rel=3D=E2=80=9Coauth_issuer"
 
OAuth defines the location of metadata under the .well-known = endpoint as a MUST. An extension of OAuth may choose from at least three = different methods for handling extensions beyond this:
1. Add additional keys to the oauth-authorization-server = metadata
2. Add additional resources to = .well-known for clients to supporting their extensions to attempt to = resolve, treating =E2=80=98regular=E2=80=99 OAuth as a fallback.
3. Define their own parameter, such as = rel=3D=E2=80=9Cspecialauth_issuer=E2=80=9D, potentially using a = different mechanism for specifying metadata
 
Given all this, it seems appropriate to = only support specifying of metadata-supplying issuers, not metadata = uris.
 
Third: I have doubts of the usefulness of resource_uri in = parallel to both the client requested URI and the Authorization = =E2=80=9Crealm=E2=80=9D parameter.
 
As currently defined, the client would = be the one enforcing (or possibly ignoring) static policy around = resource URIs - that a resource URI is arbitrary except in that it must = match the host (and scheme/port?) of the requested URI. The information = on the requested URI by the client is not shared between the client and = AS for it to do its own policy verification. It would seem better to = send the client origin to the AS for it to do (potential) policy = verification, rather than relying on clients to implement it for them = based on static spec policy.
 
The name =E2=80=9Cresource URI=E2=80=9D is also confusing, as = I would expect it to be the URI that was requested by the client. The = purpose of this parameter is a bit confusing, as it is only defined as = =E2=80=9CAn OAuth 2.0 Resource Endpoint specified in [RFC6750] section = 3.2 - where the term doesn=E2=80=99t appear in 6750 and there does not = appear to be a section 3.2 ;-)
 
It seems that:
a. If the resource_uri is = a direct match for the URI requested for the client, it is redundant and = should be dropped
    (If the resource URI is = *not* a direct match with the URI of the resource requested by the = client, it might need a better name).
b. If the resource URI is meant to provide a certain = arbitrary grouping for applying tokens within the origin of the resource = server, what is its value over the preexisting =E2=80=9C realm=E2=80=9D= parameter?
c. If the resource URI is meant to = provide a way for an AS to allow resources to be independent, identified = entities on a single origin - I=E2=80=99m unsure how a client would = understand it is meant to treat these resource URIs as independent = entities (e.g. be sure not to send bearer tokens minted for resource = /entity1 to /entity2, or for that matter prevent /entity1 from = requesting tokens for /entity2).
 
Admittedly based on not fully understanding the purpose of = this parameter, it seems to me there exists a simpler flow which better = leverages the existing Authentication mechanism of HTTP. 
 
A request would fail due to an invalid = or missing token for the realm at the origin, and and the client would = make a request to the issuer including the origin of the requested = resource as a parameter. Any other included parameters specified by the = WWW-Authenticate challenge understood by the client (such as = =E2=80=9Cscope=E2=80=9D) would also be applied to this request.
 
Normal authorization grant flow would = then happen (as this is the only grant type supported by RFC6750). Once = the access token is acquired by the client, the client associates that = token with the =E2=80=9Crealm=E2=80=9D parameter given in the initial = challenge by the resource server origin. Likewise, the =E2=80=98aud=E2=80=99= of the token as returned by a token introspection process would be the = origin of the resource server.
 
It seems any more complicated protected resource groupings on = a resource server would need a client to understand the structure of the = resource server, and thus fetch some sort of resource server = metadata.
 
Fourth and finally: Is the intention to eventually recommend = token binding here? Token binding as a requirement across clients, = resources, and the authorization servers would isolate tokens to only = being consumed within an origin. This would actually make = redundant/supplemental the AS additions defined within this spec = (resource/origin request parameter, =E2=80=98aud=E2=80=99 introspection = response member)
 
-DW


On Jun 12, 2018, at 1:28 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:
 
Hey OAuth WG
 
I have worked with Nat and Brian to = merge our concepts and those are captured in the updated draft.
 
https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/=
 
We are hopeful the WG will adopt this draft as a WG = document.
 
Any comments and feedback are welcome!
 
/Dick
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_98EFA94F-90B0-4D31-9030-B49AC8290744-- From nobody Fri Jul 20 11:39:52 2018 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 C649D130DCE for ; Fri, 20 Jul 2018 11:39:49 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4Zo6jdcBWCR for ; Fri, 20 Jul 2018 11:39:46 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id CE853129385 for ; Fri, 20 Jul 2018 11:39:45 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:f839:906b:e7ad:6493] (unknown [IPv6:2601:282:202:b210:f839:906b:e7ad:6493]) by alkaline-solutions.com (Postfix) with ESMTPSA id CCC9B31544; Fri, 20 Jul 2018 18:39:44 +0000 (UTC) From: David Waite Message-Id: <248DB7BF-2964-42DE-8CD1-879D3DDE762C@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6466AD47-9E70-4B5B-BD85-A9BAF3E9B36C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 20 Jul 2018 12:39:44 -0600 In-Reply-To: Cc: Dick Hardt , "oauth@ietf.org" To: n-sakimura References: <1AD25F21-4F76-41CA-96E8-6E09373D04E8@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 18:39:50 -0000 --Apple-Mail=_6466AD47-9E70-4B5B-BD85-A9BAF3E9B36C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There is also existing software that expects to be able to act/respond = based only on the WWW-Authenticate header. See = https://hc.apache.org/httpcomponents-client-4.5.x/httpclient/apidocs/org/a= pache/http/auth/AuthScheme.html#processChallenge(org.apache.http.Header) = = -DW > On Jul 20, 2018, at 2:33 AM, n-sakimura wrote: >=20 > Hi David,=20 > =20 > Thanks for the comment, and sorry for the delay in my reply. > =20 > Doing it with Web Linking [RFC8288] has several advantages. > =20 > It is standard based J It is just a matter of registering link = relations to the IANA Link Relation Type Registry, and it is quite = widely used. > No or very little coding needed: Other than adding some HTTP server = configuration, the rest stays the same as RFC6750. > Standard interface: this kind of metadata is applicable not only for = letting the client find the appropriate authorization server but for = other metadata as well. Also, other endpoints as long as it is = supporting the direct communication with the client, can provide = relevant metadata with it without going through the client = authorization. > =20 > I did not quite follow why CORS is relevant here. We are just talking = about the client to server communication, and there are no embedded = resources in the response. Could you kindly elaborate a little, please?=20= > =20 > For the second point, since it was discussed in the WG meeting = yesterday, I will defer to that discussion. > =20 > Best,=20 > =20 > Nat Sakimura > =20 > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of David Waite > Sent: Thursday, July 19, 2018 4:55 PM > To: Dick Hardt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] updated Distributed OAuth ID > =20 > Four comments. > =20 > First: What is the rationale for including the parameters as Link = headers rather than part of the WWW-Authenticate challenge, e.g.: > =20 > WWW-Authenticate: Bearer realm=3D"example_realm", > scope=3D"example_scope", > error=3D=E2=80=9Cinvalid_token", > resource_uri=3D"https://api.example.com/resource = ", > = oauth_server_metadata_uris=3D"https://as.example.com/.well-known/oauth-aut= horization-server = = https://different-as.example.com/.well-known/oauth-authorization-server = "= > =20 >=20 > My understanding is that the RFC6750 auth-params are extensible (but = not currently part of any managed registry.) > =20 > One reason to go with this vs Link headers is CORS policy - exposing = Link headers to a remote client must be done all or nothing as part of = the CORS policy, and can=E2=80=99t be limited by the kind of link. > =20 > Second: (retaining link format) Is there a reason the metadata = location is specified the way it is? It seems like > =20 > >; = rel=3D=E2=80=9Coauth_server_metadata_uri" > =20 > should be > =20 > >; = rel=3D=E2=80=9Coauth_issuer" > =20 > OAuth defines the location of metadata under the .well-known endpoint = as a MUST. An extension of OAuth may choose from at least three = different methods for handling extensions beyond this: > 1. Add additional keys to the oauth-authorization-server metadata > 2. Add additional resources to .well-known for clients to supporting = their extensions to attempt to resolve, treating =E2=80=98regular=E2=80=99= OAuth as a fallback. > 3. Define their own parameter, such as rel=3D=E2=80=9Cspecialauth_issuer= =E2=80=9D, potentially using a different mechanism for specifying = metadata > =20 > Given all this, it seems appropriate to only support specifying of = metadata-supplying issuers, not metadata uris. > =20 > Third: I have doubts of the usefulness of resource_uri in parallel to = both the client requested URI and the Authorization =E2=80=9Crealm=E2=80=9D= parameter. > =20 > As currently defined, the client would be the one enforcing (or = possibly ignoring) static policy around resource URIs - that a resource = URI is arbitrary except in that it must match the host (and = scheme/port?) of the requested URI. The information on the requested URI = by the client is not shared between the client and AS for it to do its = own policy verification. It would seem better to send the client origin = to the AS for it to do (potential) policy verification, rather than = relying on clients to implement it for them based on static spec policy. > =20 > The name =E2=80=9Cresource URI=E2=80=9D is also confusing, as I would = expect it to be the URI that was requested by the client. The purpose of = this parameter is a bit confusing, as it is only defined as =E2=80=9CAn = OAuth 2.0 Resource Endpoint specified in [RFC6750] section 3.2 - where = the term doesn=E2=80=99t appear in 6750 and there does not appear to be = a section 3.2 ;-) > =20 > It seems that: > a. If the resource_uri is a direct match for the URI requested for the = client, it is redundant and should be dropped > (If the resource URI is *not* a direct match with the URI of the = resource requested by the client, it might need a better name). > b. If the resource URI is meant to provide a certain arbitrary = grouping for applying tokens within the origin of the resource server, = what is its value over the preexisting =E2=80=9C realm=E2=80=9D = parameter? > c. If the resource URI is meant to provide a way for an AS to allow = resources to be independent, identified entities on a single origin - = I=E2=80=99m unsure how a client would understand it is meant to treat = these resource URIs as independent entities (e.g. be sure not to send = bearer tokens minted for resource /entity1 to /entity2, or for that = matter prevent /entity1 from requesting tokens for /entity2). > =20 > Admittedly based on not fully understanding the purpose of this = parameter, it seems to me there exists a simpler flow which better = leverages the existing Authentication mechanism of HTTP.=20 > =20 > A request would fail due to an invalid or missing token for the realm = at the origin, and and the client would make a request to the issuer = including the origin of the requested resource as a parameter. Any other = included parameters specified by the WWW-Authenticate challenge = understood by the client (such as =E2=80=9Cscope=E2=80=9D) would also be = applied to this request. > =20 > Normal authorization grant flow would then happen (as this is the only = grant type supported by RFC6750). Once the access token is acquired by = the client, the client associates that token with the =E2=80=9Crealm=E2=80= =9D parameter given in the initial challenge by the resource server = origin. Likewise, the =E2=80=98aud=E2=80=99 of the token as returned by = a token introspection process would be the origin of the resource = server. > =20 > It seems any more complicated protected resource groupings on a = resource server would need a client to understand the structure of the = resource server, and thus fetch some sort of resource server metadata. > =20 > Fourth and finally: Is the intention to eventually recommend token = binding here? Token binding as a requirement across clients, resources, = and the authorization servers would isolate tokens to only being = consumed within an origin. This would actually make = redundant/supplemental the AS additions defined within this spec = (resource/origin request parameter, =E2=80=98aud=E2=80=99 introspection = response member) > =20 > -DW >=20 >=20 > On Jun 12, 2018, at 1:28 PM, Dick Hardt > wrote: > =20 > Hey OAuth WG > =20 > I have worked with Nat and Brian to merge our concepts and those are = captured in the updated draft. > =20 > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ = > =20 > We are hopeful the WG will adopt this draft as a WG document. > =20 > Any comments and feedback are welcome! > =20 > /Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_6466AD47-9E70-4B5B-BD85-A9BAF3E9B36C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There= is also existing software that expects to be able to act/respond based = only on the WWW-Authenticate header. See

https://hc.apache.org/httpcomponents-client-4.5.x/httpclient/ap= idocs/org/apache/http/auth/AuthScheme.html#processChallenge(org.apache.htt= p.Header)

-DW

On Jul 20, 2018, at 2:33 AM, n-sakimura = <n-sakimura@nri.co.jp> wrote:

Hi David, 
 
Thanks for the comment, and sorry for the delay in my = reply.
 
Doing it with Web Linking [RFC8288]  has several = advantages.
 
  1. It is standard based J It is just a matter of = registering link relations to the IANA Link Relation Type Registry, and = it is quite widely used.
  2. No or very little coding needed: Other = than adding some HTTP server configuration, the rest stays the same as = RFC6750.
  3. Standard interface: this kind of metadata is applicable not = only for letting the client find the appropriate authorization server = but for other metadata as well. Also, other endpoints as long as it is = supporting the direct communication with the client, can provide = relevant metadata with it without going through the client = authorization.
 
I = did not quite follow why CORS is relevant here. We are just talking = about the client to server communication, and there are no embedded = resources in the response. Could you kindly elaborate a little, = please? 
 
For = the second point, since it was discussed in the WG meeting yesterday, I = will defer to that discussion.
 
Best, 
 
Nat = Sakimura
 
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of David Waite
Sent: Thursday, July 19, 2018 = 4:55 PM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] updated = Distributed OAuth ID
 
Four comments.
 
First: What is the rationale for = including the parameters as Link headers rather than part of the = WWW-Authenticate challenge, e.g.:
 
WWW-Authenticate: Bearer realm=3D"example_realm",
                =             =  scope=3D"example_scope",
      =                     =    error=3D=E2=80=9Cinvalid_token",
    resource_uri=3D"https://api.example.com/resource",

 

My understanding is that the RFC6750 = auth-params are extensible (but not currently part of any managed = registry.)
 
One reason to go with this vs Link headers is CORS policy - = exposing Link headers to a remote client must be done all or nothing as = part of the CORS policy, and can=E2=80=99t be limited by the kind of = link.
 
Second: (retaining link format) Is there a reason the = metadata location is specified the way it is? It seems like
 
<https://as.example.com/.well-known/oauth-authorization-server>; rel=3D=E2=80=9Coauth_server_metadata_uri"
should be
<https://as.example.com>; = rel=3D=E2=80=9Coauth_issuer"
 
OAuth defines the location of metadata under the .well-known = endpoint as a MUST. An extension of OAuth may choose from at least three = different methods for handling extensions beyond this:
1. Add additional keys to the oauth-authorization-server = metadata
2. Add additional resources to = .well-known for clients to supporting their extensions to attempt to = resolve, treating =E2=80=98regular=E2=80=99 OAuth as a fallback.
3. Define their own parameter, such as = rel=3D=E2=80=9Cspecialauth_issuer=E2=80=9D, potentially using a = different mechanism for specifying metadata
 
Given all this, it seems appropriate to = only support specifying of metadata-supplying issuers, not metadata = uris.
 
Third: I have doubts of the usefulness of resource_uri in = parallel to both the client requested URI and the Authorization = =E2=80=9Crealm=E2=80=9D parameter.
 
As currently defined, the client would = be the one enforcing (or possibly ignoring) static policy around = resource URIs - that a resource URI is arbitrary except in that it must = match the host (and scheme/port?) of the requested URI. The information = on the requested URI by the client is not shared between the client and = AS for it to do its own policy verification. It would seem better to = send the client origin to the AS for it to do (potential) policy = verification, rather than relying on clients to implement it for them = based on static spec policy.
 
The name =E2=80=9Cresource URI=E2=80=9D is also confusing, as = I would expect it to be the URI that was requested by the client. The = purpose of this parameter is a bit confusing, as it is only defined as = =E2=80=9CAn OAuth 2.0 Resource Endpoint specified in [RFC6750] section = 3.2 - where the term doesn=E2=80=99t appear in 6750 and there does not = appear to be a section 3.2 ;-)
 
It seems that:
a. If the resource_uri is = a direct match for the URI requested for the client, it is redundant and = should be dropped
    (If the resource URI is = *not* a direct match with the URI of the resource requested by the = client, it might need a better name).
b. If the resource URI is meant to provide a certain = arbitrary grouping for applying tokens within the origin of the resource = server, what is its value over the preexisting =E2=80=9C realm=E2=80=9D= parameter?
c. If the resource URI is meant to = provide a way for an AS to allow resources to be independent, identified = entities on a single origin - I=E2=80=99m unsure how a client would = understand it is meant to treat these resource URIs as independent = entities (e.g. be sure not to send bearer tokens minted for resource = /entity1 to /entity2, or for that matter prevent /entity1 from = requesting tokens for /entity2).
 
Admittedly based on not fully understanding the purpose of = this parameter, it seems to me there exists a simpler flow which better = leverages the existing Authentication mechanism of HTTP. 
 
A request would fail due to an invalid = or missing token for the realm at the origin, and and the client would = make a request to the issuer including the origin of the requested = resource as a parameter. Any other included parameters specified by the = WWW-Authenticate challenge understood by the client (such as = =E2=80=9Cscope=E2=80=9D) would also be applied to this request.
 
Normal authorization grant flow would = then happen (as this is the only grant type supported by RFC6750). Once = the access token is acquired by the client, the client associates that = token with the =E2=80=9Crealm=E2=80=9D parameter given in the initial = challenge by the resource server origin. Likewise, the =E2=80=98aud=E2=80=99= of the token as returned by a token introspection process would be the = origin of the resource server.
 
It seems any more complicated protected resource groupings on = a resource server would need a client to understand the structure of the = resource server, and thus fetch some sort of resource server = metadata.
 
Fourth and finally: Is the intention to eventually recommend = token binding here? Token binding as a requirement across clients, = resources, and the authorization servers would isolate tokens to only = being consumed within an origin. This would actually make = redundant/supplemental the AS additions defined within this spec = (resource/origin request parameter, =E2=80=98aud=E2=80=99 introspection = response member)
 
-DW


On Jun 12, 2018, at 1:28 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:
 
Hey OAuth WG
 
I have worked with Nat and Brian to = merge our concepts and those are captured in the updated draft.
 
https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/=
 
We are hopeful the WG will adopt this draft as a WG = document.
 
Any comments and feedback are welcome!
 
/Dick
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_6466AD47-9E70-4B5B-BD85-A9BAF3E9B36C-- From nobody Sat Jul 21 08:33:11 2018 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 7E6BF130DCF for ; Sat, 21 Jul 2018 08:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-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 3buEQ-DkQuZF for ; Sat, 21 Jul 2018 08:33:07 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 5C7AD130DD3 for ; Sat, 21 Jul 2018 08:33:06 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id b5-v6so7877423qkg.6 for ; Sat, 21 Jul 2018 08:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=oQYYephaeJc8bpxIvzxCjJDBS11OyKJQigaW+oYHeLo=; b=Xd1N2ggfVa+AIJoY/lmiSaE8YDGvdXflIhGLkuhBIA1odkDvP18k4Alap71DbJwSZt /wN4BdgTOX4SNXCLGZrImgpwMeKHNMhXWdav6usQSy1XVLgwnbSqkrtthB81yb4pPRZq Lk7rXSn/oOItSKdQ84b3SiQXRzdb6PbL9nnJ+r/CAG3gan4MomFlTQ+hhq5cnEMNkto0 mLs/nRMnJBovOPscgu4rQ7Wg6dsIM3idl2J/1CTB0Lywh5toNA0G3uYm3sKUQaQYYaN5 lS6Z3u4gI4K1jyVBEIXshh6sv3mm2Y33P3PYpJqbvT6oa4uf+EX/A2iXtuFCaSR9m6iv QDnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=oQYYephaeJc8bpxIvzxCjJDBS11OyKJQigaW+oYHeLo=; b=ooTfaucbVNmAJwYKwsLnIY6m/Lv5n6khm68PVPFEqp0Hp4/fN3cNuF1liwemvVMQUL vG3hQGtr/3cOa7KYcFPeEb4JzkjIQYd9jWrspFbst0ewdKTlU0JEKNIB+B/Gzmd6ozFB Ron4OWdYG3OfexgMAL15fiJ7toybF3vHZ0aDj5zukAUkMPxycRLoHleQ0ipFceQx9KjN aFXguaO62HVSrhD08kkyCWb0gotfB/xRnR1rumgTFn12dp33gf1VkMHVr2/q/C9mH1Mp R42muptumE3/T1MdwPNQiArurG6WC/CzHefWQMtYndUOgUhaAJqdLCAqEzII89K1AyqL foJA== X-Gm-Message-State: AOUpUlHk2lj/ilFDuq8N1rp2PNlP4DyptxjSZYHd0WerQtIuXHX4qGhM G5Z64Uknjxhc5r27bQiB03ZIrA== X-Google-Smtp-Source: AAOMgpdEHSflDZPpwFYjF82I4uVDeEVfmTMglk+23rpjkLcFEQm2dNrQgQ02LhSFqM5NlBfUrV6X2Q== X-Received: by 2002:a37:2966:: with SMTP id p99-v6mr5654478qkh.390.1532187184670; Sat, 21 Jul 2018 08:33:04 -0700 (PDT) Received: from ?IPv6:::ffff:10.254.210.216? ([192.252.136.182]) by smtp.gmail.com with ESMTPSA id 49-v6sm3253796qtu.0.2018.07.21.08.33.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jul 2018 08:33:03 -0700 (PDT) Message-ID: <5b53522f.1c69fb81.a0309.45a1@mx.google.com> MIME-Version: 1.0 To: Rifaat Shekh-Yusef , oauth From: John Bradley Date: Sat, 21 Jul 2018 11:33:01 -0400 Importance: normal X-Priority: 3 In-Reply-To: References: Content-Type: multipart/alternative; boundary="_D838896F-CD72-4B5E-9B12-9587F5907550_" Archived-At: Subject: Re: [OAUTH-WG] MTLS - IPR Disclosure X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 15:33:10 -0000 --_D838896F-CD72-4B5E-9B12-9587F5907550_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I am not aware of any IPR. Sent from Mail for Windows 10 From: Rifaat Shekh-Yusef Sent: Tuesday, July 17, 2018 10:06 AM To: oauth Subject: [OAUTH-WG] MTLS - IPR Disclosure Authors, As part of the write-up for the OAuth MTLS document, we need an IPR disclos= ure from all of you.. Are you aware of any IPR related to the following OAuth MTLS document? https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ Regards, --_D838896F-CD72-4B5E-9B12-9587F5907550_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

 

I am not aware of any IPR.

Sent from Mail for Windows = 10

 

From: <= /b>Rifaat Shekh-Yusef
Se= nt: Tuesday, July 17, 2018 10:06 AM
To: oauth
Subject: [OAUTH-WG] MTLS - IPR Disclosure<= /p>

 

Authors,

 

As part of the write-up for the OAuth MTLS doc= ument, we need an IPR disclosure from all of you..

 

Are you a= ware of any IPR related to the following OAuth MTLS document?

https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/<= /p>

 

Regards,

 =

 

= --_D838896F-CD72-4B5E-9B12-9587F5907550_-- From nobody Sat Jul 21 09:34:45 2018 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 6D329130DFF for ; Sat, 21 Jul 2018 09:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 63Tfeluk8H2N for ; Sat, 21 Jul 2018 09:34:39 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (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 AF88712F1A2 for ; Sat, 21 Jul 2018 09:34:38 -0700 (PDT) Received: from [80.187.120.149] (helo=[10.150.89.103]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fguq3-0005WK-8N; Sat, 21 Jul 2018 18:34:35 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-7573F82E-E1A9-40D4-9180-1230D213FB57; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (15F79) In-Reply-To: Date: Sat, 21 Jul 2018 18:34:34 +0200 Cc: Filip Skokan , oauth Content-Transfer-Encoding: 7bit Message-Id: <62C4BE6B-5E04-4E93-8083-A6D0895F2740@lodderstedt.net> References: <426DBA0B-CC9B-4D9D-9ED8-5AD779159638@lodderstedt.net> To: Brian Campbell X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 16:34:43 -0000 --Apple-Mail-7573F82E-E1A9-40D4-9180-1230D213FB57 Content-Type: multipart/alternative; boundary=Apple-Mail-82A14C77-EEEA-4B66-B07C-112035795D37 Content-Transfer-Encoding: 7bit --Apple-Mail-82A14C77-EEEA-4B66-B07C-112035795D37 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brian, > Am 20.07.2018 um 16:18 schrieb Brian Campbell = : >=20 > The current draft does allow multiple "resource" parameters. However, ther= e seemed to be consensus in the WG meeting yesterday that only a single "res= ource" parameter was preferable I think this makes sense for the token request. This allows the AS to audien= ce restrict and token bind the access token to a single resource server URL.= > and that a client could obtain an access token per resource (likely using a= refresh token). I think the refresh token may represent the overall grant whereas the token r= equest may issue an access token representing the whole or a subset of the o= verall grant. The question is what this means with respect to the scope. I assume scope va= lues are typically bound to a certain resource service. For example, =E2=80=9C= openid email mediacloud#read emailservice#read=E2=80=9D would match to permi= ssion on a OpenID OP, a private cloud and an email service. I therefore woul= d suggest the AS may filter the scope down to the values applicable to the r= esource server for which the access token is being minted. Another question relates to the applicable resource URIs. Do you envision an= y way to constraint the resource URIs for which an access token might be cre= ated for a particular grant? My feeling is the resource owner should have a c= hance to consent or not in order to prevent the client to access resource se= rvers the resource owner does not want it to do so. > I'm personally sympathetic to that point. But maybe it's too restrictive. I= would like to see some more text about the complexity implications of multi= ple "resource" parameters and perhaps some discouragement of doing so. As stated above, I=E2=80=99m fine with a single parameter. I could provide s= ome text on how the resource parameter could govern the AS behavior in case o= f code and refresh token grant. > I believe logical names are more potentially useful in an STS framework li= ke token exchange but should be out of scope for this work. Are you referring to logical resource names? kind regards, Torsten. > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan wrote:= >> Hi Torsten, >>=20 >> > Multiple "resource" parameters may be used to indicate that the issued t= oken is intended to be used at multiple resource servers. >>=20 >> That's already in. Furthermore what about logical names for target servic= es? Like was added in -03 of token exchange? >>=20 >> Best, >> Filip Skokan >>=20 >>=20 >>> On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt wrote: >>> I support adoption of this document. >>>=20 >>> I would like to point out (again) a single resource is not sufficient fo= r most use cases I implemented in the last couple if years. I=E2=80=98m advo= cating for enhancing the draft to support multiple resources and a clear def= inition of the relationship between resource(s) and scope. >>>=20 >>>> Am 20.07.2018 um 08:20 schrieb n-sakimura : >>>>=20 >>>> +1 >>>>=20 >>>> =20 >>>>=20 >>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell= >>>> Sent: Friday, July 20, 2018 7:42 AM >>>> To: Rifaat Shekh-Yusef >>>> Cc: oauth >>>> Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for O= Auth 2.0" >>>>=20 >>>> =20 >>>>=20 >>>> I support adoption of this document. >>>>=20 >>>> =20 >>>>=20 >>>> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' document >>>> following the positive call for adoption at the Montreal IETF meeting. >>>>=20 >>>> Here is the document: >>>> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02= >>>>=20 >>>> Please let us know by August 2nd whether you accept / object to the >>>> adoption of this document as a starting point for work in the OAuth >>>> working group. >>>>=20 >>>> Regards, >>>> Rifaat >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> =20 >>>>=20 >>>>=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 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=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-82A14C77-EEEA-4B66-B07C-112035795D37 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

Am 20.07.2018 um 16:18 schrieb Brian Campbell <= bcampbell@pingidentity.com= >:

The c= urrent draft does allow multiple "resource" parameters. However, there seeme= d to be consensus in the WG meeting yesterday that only a single "resource" p= arameter was preferable

I= think this makes sense for the token request. This allows the AS to audienc= e restrict and token bind the access token to a single resource server URL.<= /div>
and that a cli= ent could obtain an access token per resource (likely using a refresh token)= .

I think the refresh tok= en may represent the overall grant whereas the token request may issue an ac= cess token representing the whole or a subset of the overall grant.

The question is what this means with respect to the scope. I= assume scope values are typically bound to a certain resource service. For e= xample, =E2=80=9Copenid email mediacloud#read emailservice#read=E2=80=9D wou= ld match to permission on a OpenID OP, a private cloud and an email service.= I therefore would suggest the AS may filter the scope down to the values ap= plicable to the resource server for which the access token is being minted.<= /div>

Another question relates to the applicable resource= URIs. Do you envision any way to constraint the resource URIs for which an a= ccess token might be created for a particular grant? My feeling is the resou= rce owner should have a chance to consent or not in order to prevent the cli= ent to access resource servers the resource owner does not want it to do so.=

I'= m personally sympathetic to that point. But maybe it's too restrictive. I wo= uld like to see some more text about the complexity implications of multiple= "resource" parameters and perhaps some discouragement of doing so.

As stated above, I=E2=80=99m fine= with a single parameter. I could provide some text on how the resource para= meter could govern the AS behavior in case of code and refresh token grant.<= /div>
I believe logi= cal names are more potentially useful in an STS framework like token ex= change but should be out of scope for this work.

Are you referring to logical resource names?

kind regards,
Torsten.

 







On Fri, Jul 20, 2018 at 3:= 43 AM, Filip Skokan <panva.ip@gmail.com> wrote:
Hi Torsten,

> Multiple "resource" parameters may be used to indicate that the= issued token is intended to be used at multiple resource servers.

That's already in. Furthermore what about logical names for t= arget services? Like was added in -03 of token exchange?

Best= ,
Filip Skokan


On Fri, Jul 20, 20= 18 at 9:33 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
I support adoptio= n of this document.

I would like to point out (agai= n) a single resource is not sufficient for most use cases I implemented in t= he last couple if years. I=E2=80=98m advocating for enhancing the draft to s= upport multiple resources and a clear definition of the relationship between= resource(s) and scope.

Am 20.07.2018 um 08:20 schrieb n-sakim= ura <n-sakimura= @nri.co.jp>:

+1

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Beh= alf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators fo= r OAuth 2.0"

 

I support adoption of this document.

 

On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef &= lt;rifaat.ietf@gm= ail.com> wrote:

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0' doc= ument
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indi= cators-02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat


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

 


CONFIDENTIALIT= Y NOTICE: This email may contain confidential and privileged material for th= e 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 th= e sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.

____________________= ___________________________
OAuth mailing listOAuth@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



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.<= /html>= --Apple-Mail-82A14C77-EEEA-4B66-B07C-112035795D37-- --Apple-Mail-7573F82E-E1A9-40D4-9180-1230D213FB57 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyMTE2MzQzNFow IwYJKoZIhvcNAQkEMRYEFKaJSMEN/DIl3/XfuahKVvN2RdD5MIG+BgkrBgEEAYI3EAQxgbAwga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQCBjGvJVk4ZxVLjndif QVn1T7TJd/W1+tFUjVSKHviVVt55N/oFzSkgOiu951SRVUzHpmPthXTS5mGe08vCAIupCcZLQW5C 3Au4wy15edE005xv/deP9B8pT5Mw4EaNneF/JHKVykT5t2gJPAQ5PkwsQK43AgkPD6q8Pbt90B0E 4YxjkwucAdQqMctiI+40cVz6eto8aGiBNubztSk7ZRVeWit9ddeYxxVXhSWMlB2FwzbYf8dtrahv oHoZU2wOM+GiraA6dJaaIHPoTc7zElbRtAq/kGcERzZmkbptpnTy5yHKXqAztUk/lnN5RYTkOUJG AXRkZcMO87XEps00UKKTAAAAAAAA --Apple-Mail-7573F82E-E1A9-40D4-9180-1230D213FB57-- From nobody Sat Jul 21 09:40:21 2018 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 49F4D130E46 for ; Sat, 21 Jul 2018 09:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ZNCNuqaoLBIz for ; Sat, 21 Jul 2018 09:40:15 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) (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 BDB27130DFF for ; Sat, 21 Jul 2018 09:40:14 -0700 (PDT) Received: from [80.187.120.149] (helo=[10.150.89.103]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fguvS-0000Ge-Lt; Sat, 21 Jul 2018 18:40:10 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-647604C8-5B33-4C22-9498-E9776A27D3FB; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (15F79) In-Reply-To: Date: Sat, 21 Jul 2018 18:40:09 +0200 Cc: Mike Jones , Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: <47B1C568-D395-42D7-B1CC-C7A718AECB89@lodderstedt.net> References: <426DBA0B-CC9B-4D9D-9ED8-5AD779159638@lodderstedt.net> To: Dick Hardt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 16:40:20 -0000 --Apple-Mail-647604C8-5B33-4C22-9498-E9776A27D3FB Content-Type: multipart/alternative; boundary=Apple-Mail-3681D98F-F012-4B30-BFB2-586B0569A6E6 Content-Transfer-Encoding: 7bit --Apple-Mail-3681D98F-F012-4B30-BFB2-586B0569A6E6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dick, > Am 20.07.2018 um 19:46 schrieb Dick Hardt : >=20 > There are a few places where multiple resources could be used: >=20 > One is in the code flow where it is desirable to optimize the user experie= nce so that the user is granting authorization once, and not multiple times.= =20 >=20 I agree. That=E2=80=99s the reason why I=E2=80=99m advocating multiple resou= rce. > The second is in the access token request, which leads to the third instan= ce, which is in the access token. If an access token is being returned for e= ach resource, then making a single request is simpler, it seems to complicat= e the interface more. I agree. >=20 > If we want to have audience constrained access tokens, then it is safer to= have only one resource in the access token - otherwise each resource can us= e the access token to access the other resources. Yes and no. Yes because it=E2=80=99s safer to use tightly audience restricte= d access tokens. No because token binding or cert-bound access tokens can prevent abuse in su= ch a case. >=20 > All of these examples assume that it is a single AS. Supporting multiple A= S in a single request seems super complicated and wrought with security and t= rust issues. I don=E2=80=99t see a use case for multiple AS (yet ;-). kind regards, Torsten. >=20 >=20 >=20 >=20 >> On Fri, Jul 20, 2018 at 11:13 AM, Mike Jones wrote: >> While I agree that a single requested resource is the common case, enough= people have spoken up with a need for multiple requested resources over the= years that I think everyone will be better served by leaving the ability to= specify multiple requested resources in the specification. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: OAuth On Behalf Of Brian Campbell >> Sent: Friday, July 20, 2018 10:18 AM >> To: Filip Skokan >>=20 >>=20 >> Cc: oauth >> Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OA= uth 2.0" >> =20 >>=20 >> The current draft does allow multiple "resource" parameters. However, the= re seemed to be consensus in the WG meeting yesterday that only a single "re= source" parameter was preferable and that a client could obtain an access to= ken per resource (likely using a refresh token). I'm personally sympathetic= to that point. But maybe it's too restrictive. I would like to see some mor= e text about the complexity implications of multiple "resource" parameters a= nd perhaps some discouragement of doing so. I believe logical names are more= potentially useful in an STS framework like token exchange but should be ou= t of scope for this work. =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan wrote:= >>=20 >> Hi Torsten, >>=20 >> =20 >>=20 >> > Multiple "resource" parameters may be used to indicate that the issued t= oken is intended to be used at multiple resource servers. >>=20 >> =20 >>=20 >> That's already in. Furthermore what about logical names for target servic= es? Like was added in -03 of token exchange? >>=20 >>=20 >>=20 >> Best, >> Filip Skokan >>=20 >> =20 >>=20 >> =20 >>=20 >> On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt wrote: >>=20 >> I support adoption of this document. >>=20 >> =20 >>=20 >> I would like to point out (again) a single resource is not sufficient for= most use cases I implemented in the last couple if years. I=E2=80=98m advoc= ating for enhancing the draft to support multiple resources and a clear defi= nition of the relationship between resource(s) and scope. >>=20 >>=20 >> Am 20.07.2018 um 08:20 schrieb n-sakimura : >>=20 >> +1 >>=20 >> =20 >>=20 >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell >> Sent: Friday, July 20, 2018 7:42 AM >> To: Rifaat Shekh-Yusef >> Cc: oauth >> Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OA= uth 2.0" >>=20 >> =20 >>=20 >> I support adoption of this document. >>=20 >> =20 >>=20 >> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef wrote: >>=20 >> Hi all, >>=20 >> This is the call for adoption of the 'Resource Indicators for OAuth 2.0' d= ocument >> following the positive call for adoption at the Montreal IETF meeting. >>=20 >> Here is the document: >> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 >>=20 >> Please let us know by August 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> =20 >>=20 >>=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 >> _______________________________________________ >> 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 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> =20 >>=20 >>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3681D98F-F012-4B30-BFB2-586B0569A6E6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Dick,

Am 2= 0.07.2018 um 19:46 schrieb Dick Hardt <dick.hardt@gmail.com>:

<= div>
There are a few places where multiple resources could b= e used:

One is in the code flow where it is desirable to o= ptimize the user experience so that the user is granting authorization once,= and not multiple times. 

=

I agree. That=E2=80=99s the reason why I=E2=80=99m advocating= multiple resource.

=
The second is in the access token request, which leads to the third ins= tance, which is in the access token. If an access token is being returned fo= r each resource, then making a single request is simpler, it seems to compli= cate the interface more.

I agre= e.
Would you walk me through the user experience that happened= for the client to do discovery on these three resources? In other words, wh= at did the user do to get the client to call the resource and get back the 4= 01 response?

I would assume the u= ser enters the URLs or identifies the respective service providers in the ap= p (e.g. by entering her email address). The client then sends an initial req= uest as described in your draft and gets back the 401.

<= div>Doing so for several resources will give the client the AS URL for all i= nvolved resources. If the client compares the iss claims it will figure our a= ll resources are protected by the same AS and can authorize access via a sin= gle authz code grant flow.

kind regards,
= Torsten.
= --Apple-Mail-AA44DDF2-264D-4562-8CD5-3F3A7A6A046F-- --Apple-Mail-E12ECF2A-90C9-487C-BF96-94BC9F394B69 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyMTE2NDkwNVow IwYJKoZIhvcNAQkEMRYEFMvTVXKJqiZlMoJYiQRCH7UWB/0mMIG+BgkrBgEEAYI3EAQxgbAwga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQB+QLjaU1VH7jSAcJzz c84aoU9JrlZK/SOsjpsNBCwEwa0PAfnrhRe6sOuAkeoxwGJofhJHGS9OfGbPJuTBimFD8Yi/gx4W 31VLrDQu+CcyyL4xxPvmD5DtXbchg3FTAZMvvL1MzGRHMAMMevhp0FM2A+WvezeStCxgpUtCD4/g 0W6zNE5/FrqOjl9MTUEerNVNfanvYvm+6C+4aHcl8ik8qOtlC+6ix2/NATF046nTvHHcFuvIqpUh J+BYkVUZkn82OeOlwkF3EWsG8qbj1sXHm2MyueveberrA6GeS4MXzK3lNsQexVgl66PzmPUxodD5 TSxShsnbiZbB2oR2iiRxAAAAAAAA --Apple-Mail-E12ECF2A-90C9-487C-BF96-94BC9F394B69-- From nobody Sat Jul 21 09:53:53 2018 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 195A4130DC4 for ; Sat, 21 Jul 2018 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.308 X-Spam-Level: X-Spam-Status: No, score=0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=2.899, SPF_PASS=-0.001] autolearn=no 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 OzVnKZpXL9A7 for ; Sat, 21 Jul 2018 09:53:49 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.103]) (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 705B6127333 for ; Sat, 21 Jul 2018 09:53:49 -0700 (PDT) Received: from [80.187.120.149] (helo=[10.150.89.103]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fgv8c-0000iE-BP; Sat, 21 Jul 2018 18:53:46 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-8A4A1502-B77E-4B92-809A-94B29C196706; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (15F79) In-Reply-To: <670e70fd-d494-9153-9b41-5cab0eab0dd0@cozmanova.com> Date: Sat, 21 Jul 2018 18:53:45 +0200 Cc: Phil Hunt , Rob Otto , oauth Content-Transfer-Encoding: 7bit Message-Id: <69007A95-2BD2-4CF9-A6BB-0182F60E8D77@lodderstedt.net> References: <670e70fd-d494-9153-9b41-5cab0eab0dd0@cozmanova.com> To: Mark Dobrinic X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 16:53:52 -0000 --Apple-Mail-8A4A1502-B77E-4B92-809A-94B29C196706 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mark, > Am 20.07.2018 um 17:47 schrieb Mark Dobrinic : >=20 > I +1 this, thanks >=20 > but at the same time, I'm wondering what happened with the argument that > this should be solved by Token Exchange instead of Introspect? We presented two use case in London, (1) providing evidence for the RS=E2=80= =99s audit log and (2) providing/transforming tokens by a reverse proxy in f= ront of a resource server. The WG advised us to consider token exchange for (2) so the current draft on= ly addresses (1). kind regards, Torsten. >=20 > Cheers! >=20 > Mark >=20 >=20 >> On 20/07/18 17:39, Phil Hunt wrote: >> +1 adoption >>=20 >> I have always been concerned about clients doing introspection. Use of >> jwt helps because responses further restricted rather than less (jwe).=20= >>=20 >> Phil >>=20 >> On Jul 20, 2018, at 7:25 AM, Rob Otto >> > > wrote: >>=20 >>> I support this as well=20 >>>=20 >>> On Fri, 20 Jul 2018 at 15:22, Brian Campbell >>> >> > wrote: >>>=20 >>> +1 >>>=20 >>> On Thu, Jul 19, 2018 at 1:51 PM, William Denniss >>> >> > wrote: >>>=20 >>> I support adoption of this document by the working group. >>>=20 >>>=20 >>> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef >>> > wrote: >>>=20 >>> Hi all, >>>=20 >>> This is the call for adoption of the 'JWT Response for >>> OAuth Token Introspection' document following the >>> presentation by Torsten at the Montreal IETF meeting where >>> we didn't have a chance to do a call for adoption in the >>> meeting itself. >>>=20 >>> Here is presentation by Torsten: >>> https://datatracker.ietf.org/meeting/102/materials/slides-102= -oauth-sessa-jwt-response-for-oauth-token-introspection-00 >>>=20 >>> Here is the document: >>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-intro= spection-response-01 >>>=20 >>> Please let us know by August 2nd whether you accept / >>> object to the adoption of this document as a starting >>> point for work in the OAuth working group. >>>=20 >>> Regards, >>> Hannes & Rifaat >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=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 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Ping Identity >>> =20 >>> Rob Otto =20 >>> EMEA Field CTO/Solutions Architect =20 >>> robertotto@pingidentity.com =20 >>>=20 >>> c: +44 (0) 777 135 6092 =20 >>>=20 >>> Connect with us: Glassdoor logo >>> >>> LinkedIn logo twitter logo >>> facebook logo >>> youtube logo >>> Google+ logo >>> Blog logo >>> =20 >>>=20 >>> >>>=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 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-8A4A1502-B77E-4B92-809A-94B29C196706 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyMTE2NTM0NVow IwYJKoZIhvcNAQkEMRYEFH+Rn1gMO1GrlcV/2tpRV1P0eIHZMIG+BgkrBgEEAYI3EAQxgbAwga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQCMsz37Bm0dco8Fspwn ltPZlJzJNXMKx5AKRIX1csX56bWfCs21cmsvML0TaAw7XTV26DOnEq7tQZ9VL7+8IXwYU7LlaO0b PlRihujvjFUVBJH79guJ1rFCiCwEyvA64VyuSkSI0PeGxXdf9WUYBrxP9ndFErvDAAkkvXy+nIF9 4ElLTBQHGB7kN2x5Lz1V5lzvTxBNfX9UN8XOdgr7CbkIVQylj98fkNS74Gji7P6x6qjuLb2ZH2bt WdhtUhYYH5ltGuxE7Qqx0JoX6+TaW0OYVQ4p2fgwBRGsPCNF5487H3U0opmfN6SeB1OQS5vsdwGl +SEUok0wG0k8PMvU6IOPAAAAAAAA --Apple-Mail-8A4A1502-B77E-4B92-809A-94B29C196706-- From nobody Sat Jul 21 10:12:54 2018 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 0F2DD130EF8 for ; Sat, 21 Jul 2018 10:12:47 -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, MIME_QP_LONG_LINE=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 V2Fy8A1nPB0W for ; Sat, 21 Jul 2018 10:12:43 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 0AD53130E70 for ; Sat, 21 Jul 2018 10:12:43 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id a3-v6so13994137wrt.2 for ; Sat, 21 Jul 2018 10:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=kt/axhcERk0sUpxEbr1OqkJJb/b19VlHj74FZOvot8E=; b=WO0uaOQ4MLN5g7+cjVXFScvvOkML6fQyrCo/MlzduZcJ2gSJLg4CwqXwKNWB4L6Fvf 2ANIfE26CDIFeLnJH65bbdPjZw80ZlDrqme52sTsi4Gk31WYWji07Gylx7EAxmRPvr16 ioUrFXaCk8hsIFNF3B9rnAaNZYq11X7VAeeg61fB1XoENEwVJniNLKgsGHuVSlE0fajQ u6hLuNUL1pMBsrxCkMJstmQ/sRMjTcBkIcIjKndv1jsJHq/3K5tesqTfdzWJ/2AJWySP OOjDKpyE4J4dQkNqrfW3KkAHKWZ2GCWMTMpxZGlB1of0uYpecobQi2dI+PxtDJo9Fh8K BRxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=kt/axhcERk0sUpxEbr1OqkJJb/b19VlHj74FZOvot8E=; b=oINF4E1QU/Xz1iW5R4wRyPC57voy4mb3i/UDBkb7eZLVgCDHdFPhv8ebD4W/79fyZF pVEOYrH/STTvcJ/po8YvtoSe7bsAI2V4YPKsRUo9hFZFHMUovQfiEcPuSt1R04/i7WzY ZsKv3sJTOQPSErwKQXWQvcOYE19KKvhdI0sFEKKkq+ARHNfX4AeKH9ChuYxTHiOK6qSW FWQOnpTuVEYwkrMzOBasX7F9t0k7V4tO4M8RUj6IZF5t3GBl4boeiHNQ7Qf1thHI02in 60sM1QRfp2IPspaUWeroooZjve6mOcpq3Nq2KSVdVIG+P7wfEXMgFW8uzvY8RSVLx1Tu /mJQ== X-Gm-Message-State: AOUpUlGouUKNrOozcCR1nC+ynhVODT+9ywcQQUiZp38IL5aKqYriwPrI nOL50FRxINRtfgA5sO7SQQqzt+E= X-Google-Smtp-Source: AAOMgpd9Yrf1kSq8kjXpmOMiXerJa4i3umj9zLop+069nXs5q0tOzCgzg6rPMCXy6KGAlg3WJ3BG/g== X-Received: by 2002:a5d:6103:: with SMTP id v3-v6mr4525740wrt.265.1532193161250; Sat, 21 Jul 2018 10:12:41 -0700 (PDT) Received: from [192.168.0.105] (214-77-239-109.cust.centrio.cz. [109.239.77.214]) by smtp.gmail.com with ESMTPSA id s16-v6sm4118021wrq.20.2018.07.21.10.12.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jul 2018 10:12:40 -0700 (PDT) From: Filip Skokan Content-Type: multipart/alternative; boundary=Apple-Mail-290C889B-A7B8-4655-9F7D-A3E7B19F8700 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Sat, 21 Jul 2018 19:12:40 +0200 Message-Id: References: In-Reply-To: To: oauth X-Mailer: iPhone Mail (15G77) Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 17:12:53 -0000 --Apple-Mail-290C889B-A7B8-4655-9F7D-A3E7B19F8700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support the adoption or this document by the WG.=20 Filip Skokan Odesl=C3=A1no z iPhonu 19. 7. 2018 v 19:43, Rifaat Shekh-Yusef : > Hi all, >=20 > This is the call for adoption of the 'JWT Response for OAuth Token Introsp= ection' document following the presentation by Torsten at the Montreal IETF m= eeting where we didn't have a chance to do a call for adoption in the meetin= g itself. >=20 > Here is presentation by Torsten: > https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-= jwt-response-for-oauth-token-introspection-00 >=20 > Here is the document: > https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-01 >=20 > Please let us know by August 2nd whether you accept / object to the adopti= on of this document as a starting point for work in the OAuth working group.= >=20 > Regards, > Hannes & Rifaat > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-290C889B-A7B8-4655-9F7D-A3E7B19F8700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support the adoption or this document by t= he WG. 

Filip Skokan

Odesl=C3=A1no z iPhonu

19. 7. 2018 v 19:43, R= ifaat Shekh-Yusef <rifaat.ietf@g= mail.com>:

Hi all,

This is the call for adoption of th= e 'JWT Response for OAuth Token Introspection' document following the presen= tation by Torsten at the Montreal IETF meeting where we didn't have a chance= to do a call for adoption in the meeting itself.

H= ere is presentation by Torsten:
<= div>
Here is the document:


= --Apple-Mail-290C889B-A7B8-4655-9F7D-A3E7B19F8700-- From nobody Sat Jul 21 10:54:15 2018 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 1D56B130E15 for ; Sat, 21 Jul 2018 10:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 jYZowdixOXWR for ; Sat, 21 Jul 2018 10:54:11 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 07356130DCF for ; Sat, 21 Jul 2018 10:54:10 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id y19-v6so13061511qto.5 for ; Sat, 21 Jul 2018 10:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=beZKJpx5ygmyfZ4+9EeaYEcfgF2W8+CB6wuJyxPqS/0=; b=mk5IXdeaco9HJxtaJqCrHFVhzlVCnjOcMZyh5+BVfm9vs4ne9lvmLqrzboWDwmd3+P scIA058f6K2IKV9XsI8mipBveZhkA+gGndHI2BF6Yj8wgCnxbo026XGVNisptv0WelOt SUYJGdfh+fro9USA0Sg/u5Ex/ZixrkpRE+nkoqK1OGJxrYIMvwiKaDWO4OT0+WGSrijp m1NtLRH+HxLX1Ce0PlEaDhPj9BBnEdzb8SNrxpCpgC76zcEIk6pg7z+uJsBuuNSSUQLi FHUxh+1jV5AJb2itfPfgqlPhDXcy6QsE9semgorNQj8AwR3NHxjbc9oG/LcFTOm/waSM nKLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=beZKJpx5ygmyfZ4+9EeaYEcfgF2W8+CB6wuJyxPqS/0=; b=BQWxTUMss6v6/MUND65YQ4hO9TvKkdnjd3P052V58xcUxdsLYuOnUc16QD+mJ/aL77 B65wDFVwno38B6Cfkjlp9D7tqnC+uWVafpX0dUmaFnmkhJ1zmXpR1wddWN0JC7Il0Egy 5VfneJqo3ZXjcHL4Y5CNeAwsuGzZWZwFtVYmkageZ68d1E0RpfXhPREDkE8EcLkNLCRk qPq12JpH3FblN1ELiC/Z5foCD+I1jtEa4kUVWgKsWibWIhF33NoE6M5VX0sY4iuvMOpo VJXUIWRddqy30g8rwEsMOwHwoUxf545HQCDH/4js7zXfv/XuEFK/vGmmSH9Ueilwd7zD ZaVw== X-Gm-Message-State: AOUpUlF677SRRTlXVAVX9fZaivT0SFhcWfzsc7qnSgeas6OOzwjB0A35 hFe7V/+gZ/nAZ4wwB6UXww/9zlmzNnjNNkxrjN4zEADh X-Google-Smtp-Source: AAOMgpeXJjjRsGd6yYPM8c+2jekSbC/jGWk2EMbVkLml6IWvCT+TuS19L3F917Ma9Pl3XbaKWCoDR2LKqGFzV6m7qoE= X-Received: by 2002:ac8:5343:: with SMTP id d3-v6mr6376831qto.141.1532195649922; Sat, 21 Jul 2018 10:54:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:32e5:0:0:0:0:0 with HTTP; Sat, 21 Jul 2018 10:54:09 -0700 (PDT) In-Reply-To: References: From: Hans Zandbelt Date: Sat, 21 Jul 2018 19:54:09 +0200 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000070b8d605718619a7" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 17:54:14 -0000 --00000000000070b8d605718619a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 Hans. On Sat, Jul 21, 2018 at 7:12 PM, Filip Skokan wrote: > I support the adoption or this document by the WG. > > Filip Skokan > > Odesl=C3=A1no z iPhonu > > 19. 7. 2018 v 19:43, Rifaat Shekh-Yusef : > > Hi all, > > This is the call for adoption of the 'JWT Response for OAuth Token > Introspection' document following the presentation by Torsten at the > Montreal IETF meeting where we didn't have a chance to do a call for > adoption in the meeting itself. > > Here is presentation by Torsten: > https://datatracker.ietf.org/meeting/102/materials/slides- > 102-oauth-sessa-jwt-response-for-oauth-token-introspection-00 > > Here is the document: > https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt- > introspection-response-01 > > Please let us know by August 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth worki= ng > group. > > Regards, > Hannes & Rifaat > > _______________________________________________ > 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 --00000000000070b8d605718619a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

Hans.

On Sat, Jul 21, 2018 at 7:12 PM, Fil= ip Skokan <panva.ip@gmail.com> wrote:
I support the adoption or this document by = the WG.=C2=A0

Filip Skokan

Odesl=C3=A1no z=C2=A0iPhonu

19.= 7. 2018 v=C2=A019:43, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:

<= div>
= Hi all,

This is the call for adoption of the '= JWT Response for OAuth Token Introspection' document following the pres= entation by Torsten at the Montreal IETF meeting where we didn't have a= chance to do a call for adoption in the meeting itself.

Here is presentation by Torsten:

Here i= s the document:

Please let us know by August 2nd whether = you accept / object to the adoption of this document as a starting point fo= r work in the OAuth working group.

Regards,
<= div>Hannes & Rifaat
_______= ________________________________________
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/listinfo/oauth




--
--00000000000070b8d605718619a7-- From nobody Sat Jul 21 12:03:47 2018 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 B4900130934 for ; Sat, 21 Jul 2018 12:03:45 -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 6L5HF5kh99L5 for ; Sat, 21 Jul 2018 12:03:43 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 AE320130E0A for ; Sat, 21 Jul 2018 12:03:43 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id i12-v6so26911411oik.2 for ; Sat, 21 Jul 2018 12:03:43 -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=ae3x/48tqFUFQT+7zpCt4+A5Ce08BxE7DGvzOusX5a0=; b=Dbs1rXzXZsRhEFyj0qnenvEBVogrZmya9QjJPPBVmRPpyVQH+o2bTChTAy69J78F9N fwqtHhViGeqIU3wX5iSKKeoo2K/C3z4Vkd+bq/hLtETay2998bgWEcDYwR3eEgXZGESQ H1hHiGJPNsLVOB6Of0G+85fqqDp/rhIW47TgzwA6+bce+JGfvcm6F3RGunq1ueWcS6lL mahHlZIHWKDQRjE0MoEeY3txMPg2FiNDS80Pq1QhN5FRSbmn0LtZEJFWKfhV44ZHq/UM yBaC7/7OLHH8NamfrPwMQd47fiTz+X+pqXUKglavIgjO87YTSxcgxzRoaKnpJWxYyLjc eEQg== 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=ae3x/48tqFUFQT+7zpCt4+A5Ce08BxE7DGvzOusX5a0=; b=O67PSBJd1+6WYgCzZG+B6JVUSpCyx5Mz81QuXS6ppaKWaf/k3Zc13qOj7J8kK+rZoN SL4quO/V09br5jT5HF1ehUeE77QhhFbct/3O6YHkG6/TZDrXiJArEQLesfNygnaXo835 rrOGCt3wiFXdOuYG0UkynuB0xlarWnmxIPg2MccMNeUj0N5ClNhfVJBsWFvznkW4Xzfx +uzsAANIkTeQVWto05z5AiVvHoZQ/WtnOIbZMXtlV/xFzHQ35TwuacZIsk7UeuwPpKaM o5uVyZ6R1DCvEkVgnIqhLPFDAUw+So5dR0xY+1Qk2mo5SckGDq3UpP3YOUAI1pkjLMbA eBHw== X-Gm-Message-State: AOUpUlEs8a90fPHJD3GjgglBfgZiaWmkph0q1ZFr2E7w1NjbjKkrc5XZ 9F5Ks5PLIAzX9Qu+dm3D97EEU9GTJJqV628gc4FIkWc= X-Google-Smtp-Source: AAOMgpc0mJfbRCuBUj8Guhox091fJ1+ik52j6mtuo5jo1Fm9pna6BAtX7OnYaWHenK4ymX2CMogqRuYyWWXChJwTma8= X-Received: by 2002:aca:41d7:: with SMTP id o206-v6mr2708981oia.172.1532199822924; Sat, 21 Jul 2018 12:03:42 -0700 (PDT) MIME-Version: 1.0 From: Filip Skokan Date: Sat, 21 Jul 2018 21:03:31 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000002ba20105718712e9" Archived-At: Subject: [OAUTH-WG] regarding draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 19:03:46 -0000 --0000000000002ba20105718712e9 Content-Type: text/plain; charset="UTF-8" Hello, about the mentioned content-types in the current draft *jwsreq-16* in *section-10.4.1* - says to check the content type of the response is "application/jose" I believe this should be application/jwt instead in *section-10.4.2* - says to check the content type of the response is "application/json" I believe this should be application/jwt too Both to be in line with the example of fetch response from *section-5.2.3 * Best, *Filip Skokan* --0000000000002ba20105718712e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

about the mentioned c= ontent-types in the current draft jwsreq-16

in=C2=A0section-10.4.1 - says to

check the content type of the response = is "application/jose"

I believe t= his should be application/jwt in= stead

in section-10.4.2 - says to

check the cont= ent type of the response is "application/json"
<= br>
I believe this should be = application/jwt too

Both to be in line with= the example of fetch response from=C2=A0section-5.2.3=C2=A0
Best,
Filip Skokan
--0000000000002ba20105718712e9-- From nobody Sat Jul 21 14:24:59 2018 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 A367F130E15 for ; Sat, 21 Jul 2018 14:24:57 -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 MH8YEMcB6JzK for ; Sat, 21 Jul 2018 14:24:55 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 7D4A112426A for ; Sat, 21 Jul 2018 14:24:55 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id q19-v6so12637212ioh.11 for ; Sat, 21 Jul 2018 14:24:55 -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=odyMfe9Ms0p/+qPwKSIooKbwI6/BWJG2tcm+zn7IujM=; b=KH1H6STg4bUSrThAhrb3OfP19uIEPFjFLBE+uWAelQEMkARkLAQVsF/zTE4OXoZ6Kj olwMQg6lW6/f2fEHc5Cf1UaqEzmfX7aLHf10tuLtxu/CcaVce3jYXKswLIueo9Aob1VP LRXdcxHdZ/bUDWbZPfWnxvI3zqedlZRnsecOUnkO1ynwR/tZVnMkB4AU0BxRB7SehPTE 9YExxLBCVNSqKI3kItQ7zxk/SOzlJLKHcuAnUZMixBIt9wjiKfS2Z53Dz1uyJVcTuIIZ 5o3qTU7i6OLzglIdjhWiAfSEDktTmaO4f2Wz8IB1Rm3fqbmJiwpEABh8GMqRNYzRUTeT joqw== 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=odyMfe9Ms0p/+qPwKSIooKbwI6/BWJG2tcm+zn7IujM=; b=QJ2AwOiVx/U9cHSdibiezpwq0v3e2VJSnoISe7PC1y/dPUHXZVleznvrygAqfoDTGp gXoVJBn2WBUMQTbh9wU1okWda4PzuNxzEohwPDXhKZ94HKRVNc4x9paEzx6syFmIHk6q wXmKL/WxPOLSqOpEF9CtKQ3Bt+tKpbLsFHHXYxPodugw8MPLy1OAWOUBD5KJBewfhjcm e3GLMcG/GN8/PFtuHl5M6PtYnj0KH2mFsfxULSMWIYJv93e3wA5wWgWv1dvsK5PSU0dX MWSvpzjWyhzurzSVKgLjk+EoirLVe1b7Q6Wu7bZopKrFkCPGLFPW4Mm89D6gZ8kbYmhC qmdw== X-Gm-Message-State: AOUpUlHl2pl3LYb1dHK2ba0p/+J1hqXvBzgCfg0WbPJJ/VsvWl6LPi5J lsHvwCTuEzgvRdTBynxkMRt1t2zdDedzv6Ip4MOrSZA0zeM= X-Google-Smtp-Source: AAOMgpe83SuyfrwQSwmlo52xXb7tQF6MgTADRqrPTLoBxEw4SbIXOcBd7VPPc+zqMZ2NBstFmr9ujLxDi3oKQKMeHb8= X-Received: by 2002:a6b:2353:: with SMTP id j80-v6mr5166726ioj.99.1532208294583; Sat, 21 Jul 2018 14:24:54 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Sat, 21 Jul 2018 17:25:30 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000001ee2210571890b04" Archived-At: Subject: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 21:24:58 -0000 --0000000000001ee2210571890b04 Content-Type: text/plain; charset="UTF-8" All, The following is the shepherd write-up for the draft-ietf-oauth-mtls-10 document: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ Please, take a look and let us know if you have any comments. Regards, Rifaat & Hannes --0000000000001ee2210571890b04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

The following is the shepherd writ= e-up for the=C2=A0draft-ietf-oauth-mtls-10 document:

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

Regards,
=C2=A0Rifaat &= ; Hannes
--0000000000001ee2210571890b04-- From nobody Sat Jul 21 14:38:12 2018 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 7543C12426A for ; Sat, 21 Jul 2018 14:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 a2MhmTctA7oS for ; Sat, 21 Jul 2018 14:38:06 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.18.29]) (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 2105B130E3D for ; Sat, 21 Jul 2018 14:38:06 -0700 (PDT) Received: from [80.187.108.110] (helo=[10.16.27.54]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fgzZi-0001ec-Ux; Sat, 21 Jul 2018 23:38:03 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-5E5D217B-66C0-4A61-BEFF-0D731C23014C; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Sat, 21 Jul 2018 23:38:01 +0200 Cc: oauth Content-Transfer-Encoding: 7bit Message-Id: <570E9B49-9A42-453F-8401-125F5986B8DE@lodderstedt.net> References: To: Rifaat Shekh-Yusef X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 21:38:11 -0000 --Apple-Mail-5E5D217B-66C0-4A61-BEFF-0D731C23014C Content-Type: multipart/alternative; boundary=Apple-Mail-B7D01C8D-B34C-4A8B-81A4-9448C06FFDAA Content-Transfer-Encoding: 7bit --Apple-Mail-B7D01C8D-B34C-4A8B-81A4-9448C06FFDAA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rifaat, Berlin Group=E2=80=98s Nextgen PSD2 Spec (https://docs.wixstatic.com/ugd/c29= 14b_5351b289bf844c6881e46ee3561d95bb.pdf) also refers to mTLS. kind regards, Torsten. > Am 21.07.2018 um 23:25 schrieb Rifaat Shekh-Yusef := >=20 > All, >=20 > The following is the shepherd write-up for the drafts-ietf-oauth-mtls-10 d= ocument: > https://datahttps://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepher= dwriteup/tracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ >=20 > Please, take a look and let us know if you have any comments. >=20 > Regards, > Rifaat & Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-B7D01C8D-B34C-4A8B-81A4-9448C06FFDAA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Rifaat,

Berlin Group=E2=80=98s Nextgen PSD2 Sp= ec (https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee= 3561d95bb.pdf) also refers to mTLS.

kind regard= s,
Torsten.

Am 21.07.2018 um 23:25 schrieb Rifaat Sh= ekh-Yusef <rifaat.ietf@gmail.com= >:

All,<= div>
The following is the shepherd write-up for the draft= s-ietf-oauth-mtls-10 document:
<= br>
Please, take a look and let us know if you have any comments.<= /div>

Regards,
 Rifaat & Hannes
<= /div>
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-B7D01C8D-B34C-4A8B-81A4-9448C06FFDAA-- --Apple-Mail-5E5D217B-66C0-4A61-BEFF-0D731C23014C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyMTIxMzgwMVowIwYJKoZIhvcNAQkEMRYE FNio7LcAQqSRicjborNljbfVp1HBMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQBADReosPY+G9htkTT/6C4E287zBNlR 0JlsyU4GvZcpD5iIc1nquo99CeAblzjWVrwQXFvkYY1dylzRw1jgUBxWIHl+6WZzRWTptBGu9dQ8 BuQu054d34YNDBPvVLvNzO8uzR+Lt8kPd0Lt5kh0+PgWFqU/xjYcFPKkUjprhE+top1urCQBTejs INbYZPOdZyQdn14xYQflxsgr9PRIOGLxkdrKVyElDFostpQa2N6PPl+rAkP0W/xLJPOSkL8yFISH 1cCdcYluBRgGBdqYbSEKQCssU0X8FM24bOlPmqPNdALw1unhaLTIIImvLL48JAp0aXT9AsFd8zYj cKFUm4dYAAAAAAAA --Apple-Mail-5E5D217B-66C0-4A61-BEFF-0D731C23014C-- From nobody Sat Jul 21 14:58:35 2018 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 70DCD130E15 for ; Sat, 21 Jul 2018 14:58:32 -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 671OxksuFKhW for ; Sat, 21 Jul 2018 14:58:29 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 9A2FF130DE7 for ; Sat, 21 Jul 2018 14:58:29 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id l7-v6so12666779ioj.1 for ; Sat, 21 Jul 2018 14:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A4vjVoTHvAqVjDYSrkXt9npPJR5HZ9MJ+oE+hRB0q8I=; b=lvBU2EvHPjPB9lnmk/jbDl49Y7T2NHWlQpkpIFDbj793LMCIdTjvCWpyXkZa8n/La9 J5lZvDt/k9BKtCpRAuq/q4L11AdiVDcjtdvbpVRmy99b+vNpj+1RECtYzQn9PD6xgg4J QjqnyzCCPowN0WC5XMWmN1nga4L2pNXAU6FD9RgRfYahwGt8uI5TBpSfbIWp++gDKPpy 8s/gEKWM17a8HtddQX4OGYtE97LtT4aDRehLO4VnqxATGShuq2CI0qkozRF2PmpoBCz/ GeEVvfNQOSS4HED7mVe55NNHAhMTHJCFcyqcHtNXzzBaOAwqS2EbqI66Y2GJ1u1+zx14 lNaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A4vjVoTHvAqVjDYSrkXt9npPJR5HZ9MJ+oE+hRB0q8I=; b=tyD/LBr6SiXb11p1Yx92ULBseqOxn7O51F1FaqseXzCursBrxN8TDJgRSRXQ3uZ+OM 850wStX9RIh626AmVM9LPs1083fztlsg+ahqQomutC42uQBVO7nK+rlwplDWe/S58K6F 0KMWewMvlOrOXeyXtIaUNsKy4aeepQ9JM7IlIkv9eoJEY6AixzwEMpbGVuTpjlA05sWu oX47VdKKIybUYIWL9Qft/2qWipHaSzpDatoZ8F5jfj7sGYz7LBzX1UMrnwR1kzLoj5ug bw6mk/jc0aYzuPeiZqIgHzE2rKI0/7c5NtggkjKlsrMXfjK2P8KhkJL5kBwIRKYU8i1a eOjQ== X-Gm-Message-State: AOUpUlE1xSetCqTIGD0KhMF/ZNRwvPNlSNsi3tlATgO+xdGnp9urm/rk PGDodV0KKRA604JfsD5sBioGzaUK5ywLE4lzDPYOkQGh X-Google-Smtp-Source: AAOMgpeACMteXfIwP09CD13lnm0gT86qW8G/vZV1+IiYi1uYVt4AYHIh5GsoKPYiVFkMEUr3Yx29q0ilwzmNG8xWpGI= X-Received: by 2002:a6b:2353:: with SMTP id j80-v6mr5208932ioj.99.1532210308905; Sat, 21 Jul 2018 14:58:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:8402:0:0:0:0:0 with HTTP; Sat, 21 Jul 2018 14:58:28 -0700 (PDT) In-Reply-To: <570E9B49-9A42-453F-8401-125F5986B8DE@lodderstedt.net> References: <570E9B49-9A42-453F-8401-125F5986B8DE@lodderstedt.net> From: Rifaat Shekh-Yusef Date: Sat, 21 Jul 2018 17:58:28 -0400 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: multipart/alternative; boundary="0000000000002efde10571898336" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 21:58:33 -0000 --0000000000002efde10571898336 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Torsten! On Saturday, July 21, 2018, Torsten Lodderstedt wrote: > Hi Rifaat, > > Berlin Group=E2=80=98s Nextgen PSD2 Spec (https://docs.wixstatic.com/ugd/= c2914b_ > 5351b289bf844c6881e46ee3561d95bb.pdf) also refers to mTLS. > > kind regards, > Torsten. > > Am 21.07.2018 um 23:25 schrieb Rifaat Shekh-Yusef = : > > All, > > The following is the shepherd write-up for the drafts-ietf-oauth-mtls-10 > document: > https://data > > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ > tracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ > > > > 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 > > --0000000000002efde10571898336 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Torsten!


On Saturday, July 21, 2018, Torsten Lodderstedt= <torsten@lodderstedt.net= > wrote:
=
Hi Rifaat,

Berli= n Group=E2=80=98s Nextgen PSD2 Spec (https://= docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95= bb.pdf) also refers to mTLS.

kind regards,
Torsten.

Am 21.07.2018 um 23:25 schrieb Rifaat Shekh-Y= usef <rifaat.= ietf@gmail.com>:

=

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

Regards,
= =C2=A0Rifaat & Hannes
___________________= ____________________________
OAuth mailing list=
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth
--0000000000002efde10571898336-- From nobody Sun Jul 22 07:54:19 2018 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 CCD27130E42 for ; Sun, 22 Jul 2018 07:54:17 -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 Aw12cBSjMZlM for ; Sun, 22 Jul 2018 07:54:15 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 7F7BA129C6B for ; Sun, 22 Jul 2018 07:54:15 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id p17-v6so20384828itc.2 for ; Sun, 22 Jul 2018 07:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C3NBUpbPJhLEMK1IyUUrk9jpf8nj9o8d39IGKdaoc5Y=; b=QZlAoyoK97CpGky71BYDaHMZLq87PtdWPXA/88lT2kK5QxyEH+e9SPg+JCyY8HMHDo kbp8NUKChqQE5zELKk2x7O78bHNw8bb3m/jI38Qc0yh5qAxluArPj3b3mQknL5Y32dV0 sHui5pKW6CflIcCEBYH5UrHKNcYkK1Y3Z7LpM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C3NBUpbPJhLEMK1IyUUrk9jpf8nj9o8d39IGKdaoc5Y=; b=kODKQdgjnDXnn2qlRHoRLqRw0kky10FgfsNsj9JxBpP0ixn+rYeNMVpXZImB/L4K62 LgLKRadlkaSD4pII/R08wwXAVxWkLsHZGe6i+mG2p4bIFgaXmsmy5P+Ntmrwpq5osClg m7XYZ/k7x9rI80k7d/n4ZAioPh7ofQ6ubYF6MBjlBgr2JDWfCF1dO5ZC6RZ0vtQSQYS+ Hc7YpibMVCvD1+0KM/i+GVCMIw7I9XsLBT1Wa5JO33niala8IabYs3S8eUfoJi4a1BDj 2+n+r2TamoMv+8KrIbMKJ3zoOWY6Tb3UWqRJsWJA9bE9icyRZtoZGyadMqzA7D509nKd EODg== X-Gm-Message-State: AOUpUlGQkEpI6ezVmrb5K+wz4bVN6UhVg8o5CR6M1f1B3CUBcVhfQe++ Z3Fdw38A8TO+rwERcxVzm8RUQF586SYw9CrXHLfnl5ZGJZgBq3yMhtC2IkP0qQKPc8M1GLMH6e2 EurO9PLxf5+LNOQ== X-Google-Smtp-Source: AAOMgpfcMVI7rqR7MOfB9JuiFrvfZXeZENcDnF8uL5cEPKbJ3A25qSFLuXCFPjUOYkKbpbmCEZ4ACvSWxEQPA/EgZi0= X-Received: by 2002:a24:19d5:: with SMTP id b204-v6mr7458330itb.25.1532271254698; Sun, 22 Jul 2018 07:54:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6d18:0:0:0:0:0 with HTTP; Sun, 22 Jul 2018 07:53:44 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Sun, 22 Jul 2018 08:53:44 -0600 Message-ID: To: Filip Skokan Cc: oauth Content-Type: multipart/alternative; boundary="000000000000d6198b057197b3cb" Archived-At: Subject: Re: [OAUTH-WG] regarding draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 14:54:18 -0000 --000000000000d6198b057197b3cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe Filip is correct on these. On Sat, Jul 21, 2018 at 1:03 PM, Filip Skokan wrote: > Hello, > > about the mentioned content-types in the current draft *jwsreq-16* > > in *section-10.4.1* - says to > > check the content type of the response is "application/jose" > > > I believe this should be application/jwt instead > > in *section-10.4.2* - says to > > check the content type of the response is "application/json" > > > I believe this should be application/jwt too > > Both to be in line with the example of fetch response from > *section-5.2.3 * > > Best, > *Filip Skokan* > > _______________________________________________ > 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._ --000000000000d6198b057197b3cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe Filip is correct on these.

On Sat, Jul 21, 2018 at 1:0= 3 PM, Filip Skokan <panva.ip@gmail.com> wrote:
Hello,

about the mentioned content-types in the current draft jwsreq-16

in=C2=A0section-10.4.1 - says to
check the content= type of the response is "application/jose"

=
I believe this should be app= lication/jwt instead

in section-10.4.2 - says to

check the content type of the response is "application/json&qu= ot;

I believe this should be application/jwt too

B= oth to be in line with the example of fetch response from=C2=A0section-5= .2.3=C2=A0

Best,
Filip Skokan

_______________________________________________
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. --000000000000d6198b057197b3cb-- From nobody Sun Jul 22 13:23:20 2018 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 DF8E2130FFE for ; Sun, 22 Jul 2018 13:23:18 -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 jKXwei7lVREj for ; Sun, 22 Jul 2018 13:23:15 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::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 11E77124C04 for ; Sun, 22 Jul 2018 13:23:15 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id w8-v6so7317845ply.8 for ; Sun, 22 Jul 2018 13:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:subject:mime-version; bh=MklGcyT6VtJu69enHgD2wSIu/5YzlgkPB3SCowqEPag=; b=YZ9awOzLvIPY0ricXJsD+OA5uNyN+9yJr86HTrYExL8YWTZ2jSIDM5V/HsY0OYbH/J orBOtP0u/iUBQqd4AdhsAjs9MLUeV+l5pYJ2Zj5of6DycQYyd3fxR6pjQjU0HiRkEFvU s6CAJZMfr8N+VAmsLYqRKdFhSP7T//9FQL6/H4aoJdF8TIRx0Kz7w23Zav3/4yVn3fDT keDPpoFnRxndiElXtIij/41oFJxjlzn+QXyTX1StfLiYyPMBdX2yqZh/c92+qKiyMmVj t2leWYc/UbRrPcGcMM1vOuEkbS8c3hg3V0MXn5LZB1cQMR3cX2DKlUn1hLT7mPHkbQpd /3hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:subject :mime-version; bh=MklGcyT6VtJu69enHgD2wSIu/5YzlgkPB3SCowqEPag=; b=YEyLEFPdBK9EQ7I4ndGX+o4dc/g/Vdt27E5EWtjms6kGEg5K2fCe+shyqpMKpo51qT QFSs4fSvOYD4l7wkYpLyu2y4kQKr/mYIzIF1rLq32aqCLh9RRkrm2LzLu6noPjQQ9pUv a2sT5V9dSGQaRn8KOiWkw9hD+rHHJXqtiaW/CeclYvLy+BWjN8zSF50o8m90ehAVNM1n d4b4q+puod44V3BzP4BBdFJAAgFXsFo0KAI5mA1uc7X1CGPP55nNhSbAuqakRIOj/4jC LgOgdFjk8QA9coP9Qn1d6OPtztgKd+JBNOZPQvQJGZ19MAqFmhHkUCEb0QxE5ekkpSwF NPxg== X-Gm-Message-State: AOUpUlFcByEC6vzz8v3ZW/tqspkBFTZPo4c9Qki/eFWb9RK+jVnVczqh MbGg96pBUXR16Hr22fiGYx1UC5/fh90= X-Google-Smtp-Source: AAOMgpdCZl9oo0f7QnsIJPxxbIxwlf3F5PCbqkHOedT3EAmcAlHa837a5EGbpv1a4RXKVuqUU8gY7w== X-Received: by 2002:a17:902:708b:: with SMTP id z11-v6mr10034476plk.262.1532290994010; Sun, 22 Jul 2018 13:23:14 -0700 (PDT) Received: from [2404:160:8113:c643:80eb:e413:100::] ([2404:160:8113:c643:b9d1:ad04:4aa7:3c3a]) by smtp.gmail.com with ESMTPSA id r87-v6sm12292437pfb.1.2018.07.22.13.23.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 13:23:12 -0700 (PDT) Date: Mon, 23 Jul 2018 04:23:09 +0800 From: Eysz 7Words To: Oauth Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5b54e7ad_6b8b4567_19c" Archived-At: Subject: Re: [OAUTH-WG] Content of OAuth Digest, Vol 117, Issue 43 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 20:23:19 -0000 --5b54e7ad_6b8b4567_19c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Re: Contents of OAuth digest > > On Jul 22, 2018 at 10:54 PTG, wrote: > > > > 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. regarding draft-ietf-oauth-jwsreq (Filip Skokan) > 2. Shepherd write-up for draft-ietf-oauth-mtls-10 > (Rifaat Shekh-Yusef) > 3. Re: Shepherd write-up for draft-ietf-oauth-mtls-10 > (Torsten Lodderstedt) > 4. Re: Shepherd write-up for draft-ietf-oauth-mtls-10 > (Rifaat Shekh-Yusef) > 5. Re: regarding draft-ietf-oauth-jwsreq (Brian Campbell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 21 Jul 2018 21:03:31 +0200 > From: Filip Skokan > To: oauth@ietf.org > Subject: [OAUTH-WG] regarding draft-ietf-oauth-jwsreq > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hello, > > about the mentioned content-types in the current draft *jwsreq-16* > > in *section-10.4.1* - says to > > check the content type of the response is "application/jose" > > > I believe this should be application/jwt instead > > in *section-10.4.2* - says to > > check the content type of the response is "application/json" > > > I believe this should be application/jwt too > > Both to be in line with the example of fetch response from *section-5.2.3 * > > Best, > *Filip Skokan* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Sat, 21 Jul 2018 17:25:30 -0400 > From: Rifaat Shekh-Yusef > To: oauth > Subject: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10 > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > All, > > The following is the shepherd write-up for the draft-ietf-oauth-mtls-10 > document: > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ > > Please, take a look and let us know if you have any comments. > > Regards, > Rifaat & Hannes > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Sat, 21 Jul 2018 23:38:01 +0200 > From: Torsten Lodderstedt > To: Rifaat Shekh-Yusef > Cc: oauth > Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10 > Message-ID: <570E9B49-9A42-453F-8401-125F5986B8DE@lodderstedt.net> > Content-Type: text/plain; charset="utf-8" > > Hi Rifaat, > > Berlin Group?s Nextgen PSD2 Spec (https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf) also refers to mTLS. > > kind regards, > Torsten. > > > Am 21.07.2018 um 23:25 schrieb Rifaat Shekh-Yusef : > > > > All, > > > > The following is the shepherd write-up for the drafts-ietf-oauth-mtls-10 document: > > https://datahttps://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/tracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ > > > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 3717 bytes > Desc: not available > URL: > > ------------------------------ > > Message: 4 > Date: Sat, 21 Jul 2018 17:58:28 -0400 > From: Rifaat Shekh-Yusef > To: Torsten Lodderstedt > Cc: oauth > Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10 > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Thanks Torsten! > > > On Saturday, July 21, 2018, Torsten Lodderstedt > wrote: > > > Hi Rifaat, > > > > Berlin Group?s Nextgen PSD2 Spec (https://docs.wixstatic.com/ugd/c2914b_ > > 5351b289bf844c6881e46ee3561d95bb.pdf) also refers to mTLS. > > > > kind regards, > > Torsten. > > > > Am 21.07.2018 um 23:25 schrieb Rifaat Shekh-Yusef : > > > > All, > > > > The following is the shepherd write-up for the drafts-ietf-oauth-mtls-10 > > document: > > https://data > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ > > tracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ > > > > > > > > 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 > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 5 > Date: Sun, 22 Jul 2018 08:53:44 -0600 > From: Brian Campbell > To: Filip Skokan > Cc: oauth > Subject: Re: [OAUTH-WG] regarding draft-ietf-oauth-jwsreq > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > I believe Filip is correct on these. > > On Sat, Jul 21, 2018 at 1:03 PM, Filip Skokan wrote: > > > Hello, > > > > about the mentioned content-types in the current draft *jwsreq-16* > > > > in *section-10.4.1* - says to > > > > check the content type of the response is "application/jose" > > > > > > I believe this should be application/jwt instead > > > > in *section-10.4.2* - says to > > > > check the content type of the response is "application/json" > > > > > > I believe this should be application/jwt too > > > > Both to be in line with the example of fetch response from > > *section-5.2.3 * > > > > Best, > > *Filip Skokan* > > > > _______________________________________________ > > 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._ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 117, Issue 43 > ************************************** > --5b54e7ad_6b8b4567_19c Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
<= b>Re: Contents of OAuth digest


On Jul 22, 2018 at 10:54 PTG, <Oauth-Request> wrote:

Send OAuth mailing list submissions to

	oauth=40ietf.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=40ietf.org



You can reach the person managing the list at

	oauth-owner=40ietf.org



When replying, please edit your Subject line so it is more specific

than =22Re: Contents of OAuth digest...=22





Today's Topics:



   1. regarding draft-ietf-oauth-jwsreq (=46ilip Skokan)

   2. Shepherd write-up for draft-ietf-oauth-mtls-10

      (Rifaat Shekh-Yusef)

   3. Re: Shepherd write-up for draft-ietf-oauth-mtls-10

      (Torsten Lodderstedt)

   4. Re: Shepherd write-up for draft-ietf-oauth-mtls-10

      (Rifaat Shekh-Yusef)

   5. Re: regarding draft-ietf-oauth-jwsreq (Brian Campbell)





---------------------------------------------------------------------=
-



Message: 1

Date: Sat, 21 Jul 2018 21:03:31 +0200

=46rom: =46ilip Skokan <panva.ip=40gmail.com>

To: oauth=40ietf.org

Subject: =5BOAUTH-WG=5D regarding draft-ietf-oauth-jwsreq

Message-ID:

	<CALAqi=5F-=3DtXUo+=3Db+BXa06zQsd1Mp=5FwgiYtstUp8oT73KVhM0Gg=40ma=
il.gmail.com>

Content-Type: text/plain; charset=3D=22utf-8=22



Hello,



about the mentioned content-types in the current draft *jwsreq-16*



in *section-10.4.1* - says to



check the content type of the response is =22application/jose=22





I believe this should be application/jwt instead



in *section-10.4.2* - says to



check the content type of the response is =22application/json=22





I believe this should be application/jwt too



Both to be in line with the example of fetch response from *section-5=
.2.3 *



Best,

*=46ilip Skokan*

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2=
0180721/24905181/attachment.html>



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



Message: 2

Date: Sat, 21 Jul 2018 17:25:30 -0400

=46rom: Rifaat Shekh-Yusef <rifaat.ietf=40gmail.com>

To: oauth <oauth=40ietf.org>

Subject: =5BOAUTH-WG=5D Shepherd write-up for draft-ietf-oauth-mtls-1=
0

Message-ID:

	<CAGL6epJ=46tkrawOYT2j-y6nZByLLed=46UttyQXQf=5FHydMWNCkLxA=40mail=
.gmail.com>

Content-Type: text/plain; charset=3D=22utf-8=22



All,



The following is the shepherd write-up for the draft-ietf-oauth-mtls-=
10

document:

https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteu=
p/



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



Regards,

 Rifaat & Hannes

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2=
0180721/08f5fd81/attachment.html>



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



Message: 3

Date: Sat, 21 Jul 2018 23:38:01 +0200

=46rom: Torsten Lodderstedt <torsten=40lodderstedt.net>

To: Rifaat Shekh-Yusef <rifaat.ietf=40gmail.com>

Cc: oauth <oauth=40ietf.org>

Subject: Re: =5BOAUTH-WG=5D Shepherd write-up for draft-ietf-oauth-mt=
ls-10

Message-ID: <570E9B49-9A42-453=46-8401-125=465986B8DE=40loddersted=
t.net>

Content-Type: text/plain; charset=3D=22utf-8=22



Hi Rifaat,



Berlin Group=3Fs Nextgen PSD2 Spec (https://docs.wixstatic.com/ugd/c2=
914b=5F5351b289bf844c6881e46ee3561d95bb.pdf) also refers to mTLS.



kind regards,

Torsten.



> Am 21.07.2018 um 23:25 schrieb Rifaat Shekh-Yusef <rifaat.iet=
f=40gmail.com>:

> =20

> All,

> =20

> The following is the shepherd write-up for the drafts-ietf-oauth=
-mtls-10 document:

> https://datahttps://datatracker.ietf.org/doc/draft-ietf-oauth-mt=
ls/shepherdwriteup/tracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwri=
teup/

> =20

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

> =20

> Regards,

>  Rifaat & Hannes

> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=


> OAuth mailing list

> OAuth=40ietf.org

> https://www.ietf.org/mailman/listinfo/oauth

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2=
0180721/a2574dc4/attachment.html>

-------------- next part --------------

A non-text attachment was scrubbed...

Name: smime.p7s

Type: application/pkcs7-signature

Size: 3717 bytes

Desc: not available

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2=
0180721/a2574dc4/attachment.p7s>



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



Message: 4

Date: Sat, 21 Jul 2018 17:58:28 -0400

=46rom: Rifaat Shekh-Yusef <rifaat.ietf=40gmail.com>

To: Torsten Lodderstedt <torsten=40lodderstedt.net>

Cc: oauth <oauth=40ietf.org>

Subject: Re: =5BOAUTH-WG=5D Shepherd write-up for draft-ietf-oauth-mt=
ls-10

Message-ID:

	<CAGL6epKpiQxtANnymsVwnWbTz7Uz79NQMsRE7fp9vK00fGJ-PA=40mail.gmail=
.com>

Content-Type: text/plain; charset=3D=22utf-8=22



Thanks Torsten=21





On Saturday, July 21, 2018, Torsten Lodderstedt <torsten=40lodders=
tedt.net>

wrote:



> Hi Rifaat,

>

> Berlin Group=3Fs Nextgen PSD2 Spec (https://docs.wixstatic.com/u=
gd/c2914b=5F

> 5351b289bf844c6881e46ee3561d95bb.pdf) also refers to mTLS.

>

> kind regards,

> Torsten.

>

> Am 21.07.2018 um 23:25 schrieb Rifaat Shekh-Yusef <rifaat.iet=
f=40gmail.com>:

>

> All,

>

> The following is the shepherd write-up for the drafts-ietf-oauth=
-mtls-10

> document:

> https://data

> <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/sheph=
erdwriteup/>

> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdw=
riteup/

> tracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/

> <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/sheph=
erdwriteup/>

>

>

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

>

> Regards,

>  Rifaat & Hannes

>

> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=


> OAuth mailing list

> OAuth=40ietf.org

> https://www.ietf.org/mailman/listinfo/oauth

>

>

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2=
0180721/5fe9b9c5/attachment.html>



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



Message: 5

Date: Sun, 22 Jul 2018 08:53:44 -0600

=46rom: Brian Campbell <bcampbell=40pingidentity.com>

To: =46ilip Skokan <panva.ip=40gmail.com>

Cc: oauth <oauth=40ietf.org>

Subject: Re: =5BOAUTH-WG=5D regarding draft-ietf-oauth-jwsreq

Message-ID:

	<CA+k3eCSLD4ago=5FUbXDN=3DEEOuJP6vEpsEZp=46+E0O8d59aLvO5LQ=40mail=
.gmail.com>

Content-Type: text/plain; charset=3D=22utf-8=22



I believe =46ilip is correct on these.



On Sat, Jul 21, 2018 at 1:03 PM, =46ilip Skokan <panva.ip=40gmail.=
com> wrote:



> Hello,

>

> about the mentioned content-types in the current draft *jwsreq-1=
6*

>

> in *section-10.4.1* - says to

>

> check the content type of the response is =22application/jose=22=


>

>

> I believe this should be application/jwt instead

>

> in *section-10.4.2* - says to

>

> check the content type of the response is =22application/json=22=


>

>

> I believe this should be application/jwt too

>

> Both to be in line with the example of fetch response from

> *section-5.2.3 *

>

> Best,

> *=46ilip Skokan*

>

> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=


> OAuth mailing list

> OAuth=40ietf.org

> https://www.ietf.org/mailman/listinfo/oauth

>

>



-- =20

=5FCON=46IDENTIALITY NOTICE: This email may contain confidential and =
privileged =20

material for the sole use of the intended recipient(s). Any review, u=
se, =20

distribution or disclosure by others is strictly prohibited.=3F If yo=
u have =20

received this communication in error, please notify the sender immedi=
ately =20

by e-mail and delete the message and any file attachments from your =20

computer. Thank you.=5F

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2=
0180722/332f031f/attachment.html>



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



Subject: Digest =46ooter



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

OAuth mailing list

OAuth=40ietf.org

https://www.ietf.org/mailman/listinfo/oauth





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



End of OAuth Digest, Vol 117, Issue 43

**************************************
--5b54e7ad_6b8b4567_19c-- From nobody Sun Jul 22 14:14:01 2018 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 7133C130E2E for ; Sun, 22 Jul 2018 14:13: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 61Ah5o_yThbE for ; Sun, 22 Jul 2018 14:13:57 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 2AA50130DCE for ; Sun, 22 Jul 2018 14:13:57 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id 72-v6so21372923itw.3 for ; Sun, 22 Jul 2018 14:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fPH18bMoG6xug/P1aRP1YJMFTCgY5RYNJy5+JUKPomM=; b=FsrMvr1DlbWTJTvq/uEbztodk6vyP9woxmSvV66E0ZfVq2UfGtSwq1pV25M87OVcij RA5m0DPwQWdijH+3hGv7+dR7Mu6/COogl6Zg7RF+hS6kwVxpvjcrOuJxeloDhnJNS3SR 6ZUVeyQtKjNlKDXBqfb4mT3odJ/M26OMoFIcw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fPH18bMoG6xug/P1aRP1YJMFTCgY5RYNJy5+JUKPomM=; b=nu2j8RUzmoJUrAyoBVhOJiskIOY4csYxW+MuzJCBGDonUUGOaFYQL1tq3PUdmvRths fetQGTgpRcrGEjZWNSRhIAt/g7Nd4oYMl+/C9pnI4rAv++wAC2UMWMh2iaxpizujaXyK lh032WQe+k3+KAu094c5kkgzhXtEATWTg5mPKdK6wlXrtrId/mMNlxVogYFbIK+eNviK l3TWwjhZ0MvwYE5uHp5pbnwzgleyB1v0ib1lKiLmn0VaDQLlbXo+1nVWbhj/MLdCc6a3 Je584/QOeQsh/DwSTEYx5+mCjTj9L7dvSukSGdEKIULoRhW3fxqQvcemszgvdPQ5lBBH h85g== X-Gm-Message-State: AOUpUlFIe2VVfGiznGmeV47jLszp6Dp1gTWnWxHyPyKuOLeBBkgXHtM4 kJcuRLNmNQNDolUEZG36HvHr2Nc1LACz+5ZHRnWS3ue3QFUdDFzkpzpSRh9vlDPfB11ulpRisF+ 7EJaL9q9haBJW9w== X-Google-Smtp-Source: AAOMgpfbmvEVMhoBfYlrf9T1gii9PDfU5/cDXqRv9xVHYU0crq7W78dWAcGW4+DzJLrQWlfv7ki94bRlLgph6OQMm84= X-Received: by 2002:a02:3407:: with SMTP id x7-v6mr9432962jae.110.1532294036217; Sun, 22 Jul 2018 14:13:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6d18:0:0:0:0:0 with HTTP; Sun, 22 Jul 2018 14:13:25 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Sun, 22 Jul 2018 15:13:25 -0600 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="000000000000b87cba05719d0133" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 21:14:00 -0000 --000000000000b87cba05719d0133 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In (1), could it maybe say "normative extensions" rather than "normative changes"? Also Ping Identity is two words (rather than "PingIdentity"). Otherwise, it looks great. Thanks Rifaat! On Sat, Jul 21, 2018 at 3:25 PM, Rifaat Shekh-Yusef wrote: > All, > > The following is the shepherd write-up for the draft-ietf-oauth-mtls-10 > document: > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ > > 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._ --000000000000b87cba05719d0133 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In (1), could it maybe say "normative extensions= " rather than "normative changes"?

= Also Ping Identity is two words (rather than "PingIdentity").

Otherwise, it looks great. Thanks Rifaat!
=

On Sat, Jul= 21, 2018 at 3:25 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>= ; wrote:
All,
The following is the shepherd write-up for the=C2=A0draft-i= etf-oauth-mtls-10 document:

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

Regards,
=C2=A0Rifaat &= amp; Hannes

_______________________________________________
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. --000000000000b87cba05719d0133-- From nobody Sun Jul 22 14:53:49 2018 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 07281131026 for ; Sun, 22 Jul 2018 14:53:46 -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 S_hocnd_muHn for ; Sun, 22 Jul 2018 14:53:44 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 38D3D131025 for ; Sun, 22 Jul 2018 14:53:44 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id p81-v6so1222599itp.1 for ; Sun, 22 Jul 2018 14:53:44 -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=3EZcp6QTZoo/QHCbljEkSCF2Vxt8H7xN8fSZXa7uJwI=; b=mnOPLBRIOW8LNL0fV2gU4YWatECBHHKOg9PstaI4F4Qzf2k9zeXHDYOgFz2J9pdeLs l+am+yfcTb4mx4aES4MJYjk88GFDd1tzMumGJFEBqqeeqXDS6KSeAGfYLYAmW5Xv8bgA bEjNYXxJIjQIZbTZeFLN4j/JS19Gmqdo2iViCFYvJP4kSsag6UzHP5LITs0fV+Dv37Dd u17bcmSDWJ74Js+qyMzHnj0BVdAiATmgRONVUIlrWIVIDyDs+PtHR9PQl1i4s6/FHyEQ n0Hrl8O/5mBy1yBDcCr1akBJv3wwcrN7fCbyzvQasyY99+6OXboyn8CZ3ArwFaeUVqWZ xIuw== 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=3EZcp6QTZoo/QHCbljEkSCF2Vxt8H7xN8fSZXa7uJwI=; b=Gs42KLBYCCZe153KQh2l/qiC8DdSSYsz5/zRb86U00MxzAbeLaiGtUDK/bLQI+2rCr 4iPLu6CgU/dHotTRciRhiYF2HQ5jbbqXCzEQ1J5d6VKxI6Xia/XYxoChd8cJVSW9yg5w A7guDW7jEkeBY86iM0loweCAOGH1IMM0RJug+cQBWlOEd3eqa3B1mVpd0EOA69QaTeTP 1/qKibtzY9/ow+rnDQfXME6oB0CUFn4IG7ubdhOW6MYmIYPsH3kyLTEfZbIpajzQ0oVr H30n789RvbPMBibsF6QXopUcq2nwnEwUn4A0e6LkiAjeGjfyVeB0Hv5rjWrxX1/uir/c o8eA== X-Gm-Message-State: AOUpUlHnCC5xKkrCi/Xs+mLfjMnw8K4pchzRGdYzq8i2v3OuBJLuSirV cgCc7ytrpzvXKTQQvoUJsoWlQb0q8WxLdCd8EXQ= X-Google-Smtp-Source: AAOMgpctTHZ2Pb9H3MdcFhs5r130lLHbLjT+0y+9cD6IUa7dz1RlJQonKeThVXH94HerxMSQBxbPEpLbOikcIu3k/jk= X-Received: by 2002:a24:d358:: with SMTP id n85-v6mr8022770itg.67.1532296423607; Sun, 22 Jul 2018 14:53:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Sun, 22 Jul 2018 17:53:32 -0400 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="00000000000005114905719d9060" Archived-At: Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 21:53:47 -0000 --00000000000005114905719d9060 Content-Type: text/plain; charset="UTF-8" Thanks Brian! I have just made these two changes to the write-up. Regards, Rifaat On Sun, Jul 22, 2018 at 5:13 PM Brian Campbell wrote: > In (1), could it maybe say "normative extensions" rather than "normative > changes"? > > Also Ping Identity is two words (rather than "PingIdentity"). > > Otherwise, it looks great. Thanks Rifaat! > > On Sat, Jul 21, 2018 at 3:25 PM, Rifaat Shekh-Yusef > wrote: > >> All, >> >> The following is the shepherd write-up for the draft-ietf-oauth-mtls-10 >> document: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ >> >> 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.* --00000000000005114905719d9060 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Brian!

I have just made these tw= o changes to the write-up.

Regards,
=C2= =A0Rifaat


On Sun, Jul 22, 2018 at 5:13 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
In (1), could i= t maybe say "normative extensions" rather than "normative ch= anges"?

Also Ping Identity is two words (rath= er than "PingIdentity").

Otherwise, it l= ooks great. Thanks Rifaat!

=
On Sat, Jul 21, 2018 at 3:25 PM, Rifaat Shekh-Yu= sef <rifaat.ietf@gmail.com> wrote:
All,

The following is th= e shepherd write-up for the=C2=A0draft-ietf-oauth-mtls-10 document:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-mtls/shepherdwriteup/

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

Reg= ards,
=C2=A0Rifaat & Hannes

_______________________________________________
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. --00000000000005114905719d9060-- From nobody Sun Jul 22 15:02:44 2018 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 9E072131030 for ; Sun, 22 Jul 2018 15:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-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=rtfm-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 LDofixxpaE-L for ; Sun, 22 Jul 2018 15:02:36 -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 8DEE313104C for ; Sun, 22 Jul 2018 15:02:35 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id a134-v6so5064211lfe.6 for ; Sun, 22 Jul 2018 15:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3WNjvG/kgFdLrwWLnW3xOKC36mY3Fjkn4lflLZtfwao=; b=AkxwgUfKKMExGTplVQERsXXIrHPnx8kPuV1f2bklgDoJ63/fgAUcW2qPGFKlNgmIBU cB/hTJXi+9DwM8Gvia4zBTXO/K3QMS3wFrNP7dldRgM5F2mJlSEBAhzWkVkusVnV3Vd0 Ol+V5KmpzojKqWmwqClSf+PoOH2mvcPnFrzsVR1rWHQg4dpilqgu0HUqODnBC/26vaV5 PXOJT9vR6Gzn93SNV1Exu3TqIILD4NlivAIetTZVQSY6qTWMQeGxDOAsBCM2bvFzsVeI nKj4SO3GiRNLW8eisWfEFydn7Hfu3//aHD0TKAJsCdWqEi6YGyqHft1kKQS9elnCF1r0 xpgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3WNjvG/kgFdLrwWLnW3xOKC36mY3Fjkn4lflLZtfwao=; b=ZQ0mIPtc8VY6ZraLRg9h0xVLkAaeUOLV6KoJwVRvw8xBz/8MnaKD3HJX+dT6mHa256 9hZnHe1YKwflFBA2QsIwDRavUkogNJXkfPEE4P2sJBhfG/gVEttAnGO9NatTuUGthVVb RCcVevgfzNhmzx3p2l2Ej357w8+g52ICgGALCWgdLMQ+GgEHnxEKFMY+c09iCPXUx47G 8/oSjHmbF37B/wZ9DSKRApbnKsX4ZOo3q9+aXPAWZm3kZQXngF2hByPtGkMHLekLdNaX U+JizdnqOO0OLva0sRucKwXmdHwEk7EZnLW0vkBdjszczXgIa3kKgHWtBM9Y114ut5Em 674g== X-Gm-Message-State: AOUpUlHPJx6HaZBixZq4JMtNXcFuqU1GwOpcAVC7L1BEdp63JYan0smn P0uNVNRlSjKOIqUkS6kIuDZYAA0CsxwejwCGjrXvJA== X-Google-Smtp-Source: AAOMgpfawHP6sHN5Tfg+kqvt96EVXBiI0UBMfd10+GTgYbzx4smVbb3eQp/+hpvtlPO8OUGr8TFo8qvoui8mql1Vnxk= X-Received: by 2002:a19:c403:: with SMTP id u3-v6mr5654883lff.87.1532296953675; Sun, 22 Jul 2018 15:02:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Sun, 22 Jul 2018 15:01:52 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 22 Jul 2018 15:01:52 -0700 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="0000000000009d52f305719dafbe" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 22:02:42 -0000 --0000000000009d52f305719dafbe Content-Type: text/plain; charset="UTF-8" This text is fine. I have issued IETF-LC. On Mon, Jun 4, 2018 at 1:45 PM, Brian Campbell wrote: > Thanks Eric, I've added text in the just submitted -14 saying that only > the two ends of the chain are to be considered in access control policy > decisions. > > diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-14 > > htmlized: > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14 > > > On Fri, Jun 1, 2018 at 10:02 PM, Eric Rescorla wrote: > >> OK, well, it seems like it ought to say that that generator of the token >> can expect that the RP will apply an access control policy that s the union >> of the capabilities of the two ends of the chain -- and that while it might >> be less it won't be more. >> >> -Ekr >> >> >> On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> I suspect that the vast majority of time C's permissions won't matter at >>> all. But I do think there are legitimate cases where they might be >>> considered in the policy decision. One general example I can think of is a >>> customer service rep or administrator taking override type corrective >>> action on an end-user's account or transaction information (A is the >>> end-user and C is the customer service rep) that the user on their own >>> wouldn't have permission to change. >>> >>> On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorla wrote: >>> >>>> That would go a long way, I think. Do you think that C's permissions >>>> matter at all? So, say that the resource is accessible to C but not A? >>>> >>>> -Ekr >>>> >>>> >>>> >>>> >>>> On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> Hi Eric, >>>>> >>>>> Apologies for my somewhat slow response. I've honestly been unsure of >>>>> how else to try and address the comment/question. But will continue >>>>> trying... >>>>> >>>>> My expectation would be that access control decisions would be made >>>>> based on the subject of the token itself or on the current actor. And maybe >>>>> a combination of both in some situations (like, for example, the actor is >>>>> an administrator and the token allows admin level access to the stuff the >>>>> token subject would normally have access to). However, I don't believe >>>>> that nested prior actors would or should be considered in access control >>>>> decisions. The nesting is more just to express what has happened for >>>>> auditing or tracking or the like. To be honest, the nesting was added in >>>>> the draft largely because the structure naturally and easily allowed for it >>>>> and it seemed like it might be useful information to convey in some cases. >>>>> >>>>> So in that A->B->C case (the claims of such a token would, I think, >>>>> look like the JSON below), B *is not* giving C his authority. B is >>>>> just noted in the token as having been involved previously. While A is >>>>> identified as the subject of the token and C is the current actor. >>>>> >>>>> { >>>>> "aud":"... ,"iss":... , "exp":..., etc. etc. ... >>>>> "sub":"A", >>>>> "act": >>>>> { >>>>> "sub":"C", >>>>> "act": >>>>> { >>>>> "sub":"B" >>>>> } >>>>> } >>>>> } >>>>> >>>>> >>>>> Would some text explicitly saying that only the token subject (top >>>>> level sub and claims) and the party identified by the outermost "act" claim >>>>> (the current actor) are to be considered in access control decisions >>>>> address your concern? >>>>> >>>>> >>>>> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla wrote: >>>>> >>>>>> Hi Brian, >>>>>> >>>>>> To be clear, I'm not opposing Delegation. My concern here is that we >>>>>> have a chain of signed assertions and I'm trying to understand how I as a >>>>>> consumer of those assertions am supposed to evaluate it. >>>>>> >>>>>> I don't think it's sufficient to just say that that the access >>>>>> control rules are local policy, because then the entity generating the >>>>>> signature has no way of knowing how its signature will be used. >>>>>> >>>>>> To go back to the case I gave in my initial e-mail, say we have a >>>>>> chain A->B->C and a resource that A and C could ordinarily not access, but >>>>>> B can. If C has this delegation, can C access the resource? I.e., is B >>>>>> giving C his authority or just passing on A's authority? It seems pretty >>>>>> important for B to know that before he gives the token to C. >>>>>> >>>>>> -Ekr >>>>>> >>>>>> >>>>>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell < >>>>>> bcampbell@pingidentity.com> wrote: >>>>>> >>>>>>> Delegation has been in the document since its inception and >>>>>>> throughout the three and a half years as a working group document. >>>>>>> >>>>>>> From a process point of view, the document is now in AD Evaluation. >>>>>>> I worked through a number of questions and clarifications with Eric (said >>>>>>> AD), however he raised the particular questions that started this thread on >>>>>>> the WG list. And I responded with an attempt at addressing those questions. >>>>>>> That was about a month ago. >>>>>>> >>>>>>> Eric, was my explanation helpful in clarify anything for you? Is >>>>>>> there some text that you'd like to see added? Something else? I'm unsure >>>>>>> how to proceed but would like to move things forward. >>>>>>> >>>>>>> >>>>>>> On Thu, May 17, 2018 at 8:03 AM, Bill Burke >>>>>>> wrote: >>>>>>> >>>>>>>> This is an honest question: How important is the actor stuff to the >>>>>>>> players involved? Are people going to use it? IMO, its an edge >>>>>>>> case >>>>>>>> and I think more important areas, like external token exchange >>>>>>>> (realm >>>>>>>> to realm, domain to domain) are being neglected. I'm quite >>>>>>>> unfamiliar >>>>>>>> how consensus is reached in this WG or the IETF, so I hope I'm not >>>>>>>> sounding rude. Just trying to provide some constructive feedback. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, May 17, 2018 at 9:26 AM, Mike Jones < >>>>>>>> Michael.Jones@microsoft.com> wrote: >>>>>>>> > Moving the actor claim to a separate specification would only >>>>>>>> make things more complicated for developers. There already plenty of OAuth >>>>>>>> specs. Needlessly adding another one will only make related things harder >>>>>>>> to find. >>>>>>>> > >>>>>>>> > Just like in the JWT [RFC 7519] spec itself in which use of all >>>>>>>> the claims is optional, use of the actor claim in this spec. If you don't >>>>>>>> need it, don't use it. Just because some won't use it is no better an >>>>>>>> argument for moving it to a different spec than the argument that JWT >>>>>>>> should have defined each of its claims in different specs. That would have >>>>>>>> made things harder, not easier. >>>>>>>> > >>>>>>>> > -- Mike >>>>>>>> > >>>>>>>> > -----Original Message----- >>>>>>>> > From: OAuth On Behalf Of Bill Burke >>>>>>>> > Sent: Thursday, May 17, 2018 2:11 PM >>>>>>>> > To: Brian Campbell >>>>>>>> > Cc: oauth >>>>>>>> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang >>>>>>>> e-12.txt >>>>>>>> > >>>>>>>> > My personal opinion is that I'm glad this actor stuff is optional. >>>>>>>> > For one, none of our users have asked for it and really only do >>>>>>>> simple exchanges. Secondly, the rules for who can exchange what for what >>>>>>>> is controlled and defined within our AS. Makes things a lot simpler on the >>>>>>>> client. I kind of wish the actor stuff would be defined in a separate >>>>>>>> specification. I don't see us implementing it unless users start asking us >>>>>>>> to. >>>>>>>> > >>>>>>>> > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell < >>>>>>>> bcampbell@pingidentity.com> wrote: >>>>>>>> >> Well, it's already called the "actor claim" so the claimed part >>>>>>>> is >>>>>>>> >> kind of implied. And "claimed actor claim" is a rather awkward. >>>>>>>> >> Really, all JWT claims are "claimed something" but they don't >>>>>>>> include >>>>>>>> >> the "claimed" bit in the name. RFC 7519, for example, defines the >>>>>>>> >> subject claim but not the claimed subject claim. >>>>>>>> >> >>>>>>>> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis >>>>>>>> wrote: >>>>>>>> >>> >>>>>>>> >>> Brian, >>>>>>>> >>> >>>>>>>> >>> Eric said: "what is the RP supposed to do when they encounter >>>>>>>> it? >>>>>>>> >>> This seems kind of under specified". >>>>>>>> >>> >>>>>>>> >>> After reading your explanations below, it looks like the RP can >>>>>>>> do >>>>>>>> >>> anything he wants with the "actor". >>>>>>>> >>> It is a "claimed actor" and, if we keep the concept, it should >>>>>>>> be >>>>>>>> >>> called as such. Such a claim cannot be verified. >>>>>>>> >>> A RP could copy and paste that claim in an audit log. No >>>>>>>> standard >>>>>>>> >>> action related to the content of such a claim can be specified >>>>>>>> in the >>>>>>>> >>> spec. If the content of a "claimed actor" is used by the RP, it >>>>>>>> >>> should be only used as an hint and thus be subject to other >>>>>>>> >>> verifications which are not specified in this specification. >>>>>>>> >>> >>>>>>>> >>> Denis >>>>>>>> >>> >>>>>>>> >>> Eric, I realize you weren't particularly impressed by my prior >>>>>>>> >>> statements about the actor claim but, for lack of knowing what >>>>>>>> else >>>>>>>> >>> to say, I'm going to kind of repeat what I said about it over >>>>>>>> in the >>>>>>>> >>> Phabricator tool and add a little color. >>>>>>>> >>> >>>>>>>> >>> The actor claim is intended as a way to express that delegation >>>>>>>> has >>>>>>>> >>> happened and identify the entities involved. Access control or >>>>>>>> other >>>>>>>> >>> decisions based on it are at the discretion of the consumer of >>>>>>>> the >>>>>>>> >>> token based on whatever policy might be in place. >>>>>>>> >>> >>>>>>>> >>> There are JWT claims that have concise processing rules with >>>>>>>> respect >>>>>>>> >>> to whether or not the JWT can be accepted as valid. Some >>>>>>>> examples are "aud" >>>>>>>> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) >>>>>>>> from RFC 7519. >>>>>>>> >>> E.g. if the token is expired or was intended for someone or >>>>>>>> something >>>>>>>> >>> else, reject it. >>>>>>>> >>> >>>>>>>> >>> And there are JWT claims that appropriately don't specify such >>>>>>>> >>> processing rules and are solely statements of fact or >>>>>>>> circumstance. >>>>>>>> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) >>>>>>>> claims are good examples of such. >>>>>>>> >>> There might be application or policy specific rules applied to >>>>>>>> the >>>>>>>> >>> content of those kinds of claims (e.g. only subjects from a >>>>>>>> >>> particular organization are able to access tenant specific data >>>>>>>> or, >>>>>>>> >>> less realistic but still possible, disallow access for tokens >>>>>>>> issued >>>>>>>> >>> outside of regular business >>>>>>>> >>> hours) but that's all outside the scope of a specification's >>>>>>>> >>> definition of the claim. >>>>>>>> >>> >>>>>>>> >>> The actor claim falls into the latter category. It's a way for >>>>>>>> the >>>>>>>> >>> issuer of the token to tell the consumer of the token what is >>>>>>>> going >>>>>>>> >>> on. But any action to take (or not) based on that information >>>>>>>> is at >>>>>>>> >>> the discretion of the token consumer. I honestly don't know it >>>>>>>> could >>>>>>>> >>> be anything more. And don't think it should be. >>>>>>>> >>> >>>>>>>> >>> There are two main expected uses of the actor claim (that I'm >>>>>>>> aware >>>>>>>> >>> of >>>>>>>> >>> anyway) that describing here might help. Maybe. One is a human >>>>>>>> to >>>>>>>> >>> human delegation case like a customer service rep doing >>>>>>>> something on >>>>>>>> >>> behalf of an end user. The subject would be that user and the >>>>>>>> actor >>>>>>>> >>> would be the customer service rep. And there wouldn't be any >>>>>>>> chaining >>>>>>>> >>> or nesting of the actor. The other case is so called service >>>>>>>> chaining >>>>>>>> >>> where a system might exchange a token it receives for a new >>>>>>>> token >>>>>>>> >>> that it can use to call a downstream service. And that service >>>>>>>> in >>>>>>>> >>> turn might do another exchange to get a new token suitable to >>>>>>>> call >>>>>>>> >>> yet another downstream service. And again and so on and turtles >>>>>>>> all >>>>>>>> >>> the way. I'm not necessarily endorsing that level of >>>>>>>> granularity in >>>>>>>> >>> chaining but it's bound to happen somewhere/sometime. The nested >>>>>>>> >>> actor claim is able to express that all that has happened with >>>>>>>> the >>>>>>>> >>> top level or outermost one being the system currently using the >>>>>>>> token >>>>>>>> >>> and prior systems being nested.. What actually gets done with >>>>>>>> that >>>>>>>> >>> information is up to the respective systems involved. There >>>>>>>> might be >>>>>>>> >>> policy about what system is allowed to call what other system >>>>>>>> that is >>>>>>>> >>> enforced. Or maybe the info is just written to an audit log >>>>>>>> >>> somewhere. Or something else. I don't know. But whatever it is >>>>>>>> application/deployment/policy dependent and not specifiable by a spec. >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla >>>>>>>> wrote: >>>>>>>> >>>> >>>>>>>> >>>> Hi folks, >>>>>>>> >>>> >>>>>>>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things >>>>>>>> seem >>>>>>>> >>>> generally OK. I do still have one remaining concern, which is >>>>>>>> about >>>>>>>> >>>> the actor claim. Specifically, what is the RP supposed to do >>>>>>>> when >>>>>>>> >>>> they encounter it? This seems kind of underspecified. >>>>>>>> >>>> >>>>>>>> >>>> In particular: >>>>>>>> >>>> >>>>>>>> >>>> 1. What facts am I supposed to know here? Merely that everyone >>>>>>>> in >>>>>>>> >>>> the chain signed off on the next person in the chain acting >>>>>>>> as them? >>>>>>>> >>>> >>>>>>>> >>>> 2. Am I just supposed to pretend that the person presenting >>>>>>>> the token >>>>>>>> >>>> is the identity at the top of the chain? Say I have the >>>>>>>> >>>> delegation A -> B -> C, and there is some resource which >>>>>>>> >>>> B can access but A and C cannot, should I give access? >>>>>>>> >>>> >>>>>>>> >>>> I think the first question definitely needs an answer. The >>>>>>>> second >>>>>>>> >>>> question I guess we could make not answer, but it's pretty >>>>>>>> hard to >>>>>>>> >>>> know how to make a system with this left open.. >>>>>>>> >>>> >>>>>>>> >>>> -Ekr >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> _______________________________________________ >>>>>>>> >>>> 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. >>>>>>>> >> _______________________________________________ >>>>>>>> >> OAuth mailing list >>>>>>>> >> OAuth@ietf.org >>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >> >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > -- >>>>>>>> > Bill Burke >>>>>>>> > Red Hat >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > OAuth mailing list >>>>>>>> > OAuth@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Bill Burke >>>>>>>> Red Hat >>>>>>>> >>>>>>> >>>>>>> >>>>>>> *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.* >>>>> >>>> >>>> >>> >>> *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.* > --0000000000009d52f305719dafbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This text is fine. I have issued IETF-LC.

On Mon, Jun 4, 2018 at 1= :45 PM, Brian Campbell <bcampbell@pingidentity.com>= wrote:
Thanks Eric= , I've added text in the just submitted -14 saying that only the two en= ds of the chain are to be considered in access control policy decisions.

diff:



On Fri, Jun 1, 2018 at 10:02 PM, Eric Rescorla <ekr@rtfm.com&g= t; wrote:
OK= , well, it seems like it ought to say that that generator of the token can = expect that the RP will apply an access control policy that s the union of = the capabilities of the two ends of the chain -- and that while it might be= less it won't be more.

-Ekr

On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell <bcampbell@pingid= entity.com> wrote:
I suspect that the vast majority of time C's permissions = won't matter at all. But I do think there are legitimate cases where th= ey might be considered in the policy decision. One general example I can th= ink of is a customer service rep or administrator taking override type corr= ective action on an end-user's account or transaction information (A is= the end-user and C is the customer service rep) that the user on their own= wouldn't have permission to change. =C2=A0

On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
<= div>That would go a long way, I think. Do you think that C's permission= s matter at all? So, say that the resource is accessible to C but not A?

-Ekr



On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell <bcampb= ell@pingidentity.com> wrote:
Hi Eric,

Apologies fo= r my somewhat slow response. I've honestly been unsure of how else to t= ry and address the comment/question. But will continue trying...=C2=A0
=

My expectation would be that access control decis= ions would be made based on the subject of the token itself or on the curre= nt actor. And maybe a combination of both in some situations (like, for exa= mple, the actor is an administrator and the token allows admin level access= to the stuff the token subject would normally have access to).=C2=A0 Howev= er, I don't believe that nested prior actors would or should be conside= red in access control decisions. The nesting is more just to express what h= as happened for auditing or tracking or the like. To be honest, the nesting= was added in the draft largely because the structure naturally and easily = allowed for it and it seemed like it might be useful information to convey = in some cases.

So in that A->B->C case = (the claims of such a token would, I think, look like the JSON below), B is not giving C his=C2=A0authority. B is just noted in the token as ha= ving been involved previously.=C2=A0 While A is identified as the subject o= f the token and C is the current actor. 

    {
      "aud":"... ,"iss":... , "exp":...,=
 etc. etc. ...
      "sub":"A",
      "act":
      {
        "sub":"C",
        "act":
        {
          "sub":"B"
        }
      }
    }

Would some text explicitly saying that only the t= oken subject (top level sub and claims) and the party identified by the out= ermost "act" claim (the current actor) are to be considered in ac= cess control decisions address your concern?


On Tue, May 29, 2018 at 4:19 PM, = Eric Rescorla <ekr@rtfm.com> wrote:
Hi Brian,

To be clear,= I'm not opposing Delegation. My concern here is that we have a chain o= f signed assertions and I'm trying to understand how I as a consumer of= those assertions am supposed to evaluate it.

I do= n't think it's sufficient to just say that that the access control = rules are local policy, because then the entity generating the signature ha= s no way of knowing how its signature will be used.

To go back to the case I gave in my initial e-mail, say we have a chain A= ->B->C and a resource that A and C could ordinarily not access, but B= can. If C has this delegation, can C access the resource? I.e., is B givin= g C his authority or just passing on A's authority? It seems pretty imp= ortant for B to know that before he gives the token to C.
-Ekr


<= div class=3D"gmail_quote">
On Thu, May 17, 2018 at 11:06 AM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:
Delegation has been in the document since its inception and throug= hout the three and a half years as a working group document.

From a process point of view, the document is now in=C2=A0A= D Evaluation. I worked through a number of questions and clarifications wit= h Eric (said AD), however he raised the particular questions that started t= his thread on the WG list. And I responded with an attempt at addressing th= ose questions. That was about a month ago.

Er= ic, was my explanation helpful in clarify anything for you? Is there some t= ext that you'd like to see added? Something else? I'm unsure how to= proceed but would like to move things forward.


On Thu, May 17, 2018 at 8:03 AM= , Bill Burke <bburke@redhat.com> wrote:
This is an honest question: How important is the actor stuff = to the
players involved?=C2=A0 Are people going to use it?=C2=A0 IMO, its an edge = case
and I think more important areas, like external token exchange (realm
to realm, domain to domain) are being neglected.=C2=A0 I'm quite unfami= liar
how consensus is reached in this WG or the IETF, so I hope I'm not
sounding rude.=C2=A0 Just trying to provide some constructive feedback.



On Thu, May 17, 2018 at 9:26 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:
> Moving the actor claim to a separate specification would only make thi= ngs more complicated for developers.=C2=A0 There already plenty of OAuth sp= ecs.=C2=A0 Needlessly adding another one will only make related things hard= er to find.
>
> Just like in the JWT [RFC 7519] spec itself in which use of all the cl= aims is optional, use of the actor claim in this spec.=C2=A0 If you don'= ;t need it, don't use it.=C2=A0 Just because some won't use it is n= o better an argument for moving it to a different spec than the argument th= at JWT should have defined each of its claims in different specs.=C2=A0 Tha= t would have made things harder, not easier.
>
>=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-- Mike
>
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke
> Sent: Thursday, May 17, 2018 2:11 PM
> To: Brian Campbell <bcampbell@pingidentity.com>
> Cc: oauth <oaut= h@ietf.org>
> Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
>
> My personal opinion is that I'm glad this actor stuff is optional.=
> For one, none of our users have asked for it and really only do simple= exchanges.=C2=A0 Secondly, the rules for who can exchange what for what is= controlled and defined within our AS.=C2=A0 Makes things a lot simpler on = the client.=C2=A0 I kind of wish the actor stuff would be defined in a sepa= rate specification.=C2=A0 I don't see us implementing it unless users s= tart asking us to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Well, it's already called the "actor claim" so the c= laimed part is
>> kind of implied. And "claimed actor claim" is a rather a= wkward.
>> Really, all JWT claims are "claimed something" but they = don't include
>> the "claimed" bit in the name. RFC 7519, for example, de= fines the
>> subject claim but not the claimed subject claim.
>>
>> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> wrote:
>>>
>>> Brian,
>>>
>>> Eric said: "what is the RP supposed to do when they encou= nter it?
>>> This seems kind of under specified".
>>>
>>> After reading your explanations below, it looks like the RP ca= n do
>>> anything he wants with the "actor".
>>> It is a "claimed actor" and, if we keep the concept,= it should be
>>> called as such. Such a claim cannot be verified.
>>> A RP could copy and paste that claim in an audit log. No stand= ard
>>> action related to the content of such a claim can be specified= in the
>>> spec. If the content of a "claimed actor" is used by= the RP, it
>>> should be only used as an hint and thus be subject to other >>> verifications which are not specified in this specification. >>>
>>> Denis
>>>
>>> Eric, I realize you weren't particularly impressed by my p= rior
>>> statements about the actor claim but, for lack of knowing what= else
>>> to say, I'm going to kind of repeat what I said about it o= ver in the
>>> Phabricator tool and add a little color.
>>>
>>> The actor claim is intended as a way to express that delegatio= n has
>>> happened and identify the entities involved. Access control or= other
>>> decisions based on it are at the discretion of the consumer of= the
>>> token based on whatever policy might be in place.
>>>
>>> There are JWT claims that have concise processing rules with r= espect
>>> to whether or not the JWT can be accepted as valid. Some examp= les are "aud"
>>> (Audience), "exp" (Expiration Time), and "nbf&q= uot; (Not Before) from RFC 7519.
>>> E.g. if the token is expired or was intended for someone or so= mething
>>> else, reject it.
>>>
>>> And there are JWT claims that appropriately don't specify = such
>>> processing rules and are solely statements of fact or circumst= ance.
>>> Also from RFC 7519, the "sub" (Subject) and "ia= t" (Issued At) claims are good examples of such.
>>> There might be application or policy specific rules applied to= the
>>> content of those kinds of claims (e.g. only subjects from a >>> particular organization are able to access tenant specific dat= a or,
>>> less realistic but still possible, disallow access for tokens = issued
>>> outside of regular business
>>> hours) but that's all outside the scope of a specification= 's
>>> definition of the claim.
>>>
>>> The actor claim falls into the latter category. It's a way= for the
>>> issuer of the token to tell the consumer of the token what is = going
>>> on. But any action to take (or not) based on that information = is at
>>> the discretion of the token consumer. I honestly don't kno= w it could
>>> be anything more. And don't think it should be.
>>>
>>> There are two main expected uses of the actor claim (that I= 9;m aware
>>> of
>>> anyway) that describing here might help. Maybe. One is a human= to
>>> human delegation case like a customer service rep doing someth= ing on
>>> behalf of an end user. The subject would be that user and the = actor
>>> would be the customer service rep. And there wouldn't be a= ny chaining
>>> or nesting of the actor. The other case is so called service c= haining
>>> where a system might exchange a token it receives for a new to= ken
>>> that it can use to call a downstream service. And that service= in
>>> turn might do another exchange to get a new token suitable to = call
>>> yet another downstream service. And again and so on and turtle= s all
>>> the way. I'm not necessarily endorsing that level of granu= larity in
>>> chaining but it's bound to happen somewhere/sometime. The = nested
>>> actor claim is able to express that all that has happened with= the
>>> top level or outermost one being the system currently using th= e token
>>> and prior systems being nested.. What actually gets done with = that
>>> information is up to the respective systems involved. There mi= ght be
>>> policy about what system is allowed to call what other system = that is
>>> enforced. Or maybe the info is just written to an audit log >>> somewhere. Or something else. I don't know. But whatever i= t is application/deployment/policy dependent and not specifiable by a spec.=
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I've gone over draft-ietf-oauth-token-exchange-12= and things seem
>>>> generally OK. I do still have one remaining concern, which= is about
>>>> the actor claim. Specifically, what is the RP supposed to = do when
>>>> they encounter it? This seems kind of underspecified.
>>>>
>>>> In particular:
>>>>
>>>> 1. What facts am I supposed to know here? Merely that ever= yone in
>>>>=C2=A0 =C2=A0 the chain signed off on the next person in th= e chain acting as them?
>>>>
>>>> 2. Am I just supposed to pretend that the person presentin= g the token
>>>>=C2=A0 =C2=A0 is the identity at the top of the chain? Say = I have the
>>>>=C2=A0 =C2=A0 delegation A -> B -> C, and there is so= me resource which
>>>>=C2=A0 =C2=A0 B can access but A and C cannot, should I giv= e access?
>>>>
>>>> I think the first question definitely needs an answer. The= second
>>>> question I guess we could make not answer, but it's pr= etty hard to
>>>> know how to make a system with this left open..
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/oauth
>>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d
>>> privileged material for the sole use of the intended recipient= (s).
>>> Any review, use, distribution or disclosure by others is stric= tly
>>> 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/o= auth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>
>>
>> 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 erro= r, 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=
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth=



--
Bill Burke
Red Hat


CONFIDENTIALITY NOTICE: This email may contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited.=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le 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.



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



<= 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.
--0000000000009d52f305719dafbe-- From nobody Sun Jul 22 15:53:16 2018 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 315CD130E3C for ; Sun, 22 Jul 2018 15:53:14 -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 8X1nDDTbatye for ; Sun, 22 Jul 2018 15:53:12 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 E5F9B12426A for ; Sun, 22 Jul 2018 15:53:11 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id a26-v6so532558pfo.4 for ; Sun, 22 Jul 2018 15:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B6H7jkXjfqctHtXhUtBs+wlTUU6RfJcykkIIipZEtas=; b=kdN05g4l6AkNLfViIm6RiGxMpA+FBP782yQ9QhArN5AwWNEr3gLhNeIBEDqHF6Jp12 COFMvaBkwx8JMUsUpHpZjxaTtkD8yfOFZNeLeqHiEiW4vXRVCsVinFXdJzWddLpUmFCb K0AqKNmB5WR0IVxlmRy5f2mzhlETI71mqeRBxO0+0Lhl53tD830iG0AASe4uVjOqoYPL 8IRIHQD4IwCgIzvpz7vPJQ2s4d5KxbTilITdR03gDjk3YW0Mxrxt0D3q+exiXD83V8Kg +FwiqZTgyLJADmrR1jSS3wKdxXVb8oGRceFpa/dn6n8vcleNW4NYqqflSOEP8R3hZwsv j+9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B6H7jkXjfqctHtXhUtBs+wlTUU6RfJcykkIIipZEtas=; b=E+OuIRyknO5tTFL0t9VyQHFmiaOrnRx8Qqh8i5CGv0mlEcHhQoeC289VYMupH5ZVIL ZQNnPG+/5hOgR/s4ffIryn4Lacwe98w4H8AgeyFdilMbSE4R4B8dBjokDZGVKg+t2A8d Mvg28oKh4wMjXB23un3ZOkdeVtjl0DcLd1C+8rN1WoJLj+K7E08u+cVf5pV1vVacNMbl FmocV7jlG9Obb7wVuIZdwrxk6AW6diZmNLcDcACp3DZX42Gyu3v+radsLqHmKbBxDqjd uKHLAWQjmX50L7Bx7DnS0TDI2I1uQQ+/I7JIuDj6edwTwlZUP2IGeew8AsW7RqzKA0tM H7tw== X-Gm-Message-State: AOUpUlEY49S5wqrrqjVZjkyvCjbZFKYa+dN6W6Jy1pdFOA1C3PobMIsf s4x9KI0fkuXjCORbsDi+2QOv/eTVU+BVmgvdaP2pJg== X-Google-Smtp-Source: AAOMgpc6icko4HZLhuk3jA9Q66dig4AjCZEKXWDmBqyDXubiv1q/OIXrACyZGegHI7oTGhK1Pvp/iY/zx5H19pL4/nc= X-Received: by 2002:a63:6243:: with SMTP id w64-v6mr9906239pgb.179.1532299991468; Sun, 22 Jul 2018 15:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Sun, 22 Jul 2018 15:52:50 -0700 (PDT) In-Reply-To: <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> From: Dick Hardt Date: Sun, 22 Jul 2018 18:52:50 -0400 Message-ID: To: Torsten Lodderstedt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000ae506b05719e64cc" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 22:53:14 -0000 --000000000000ae506b05719e64cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 21, 2018 at 12:49 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Dick, > > Am 19.07.2018 um 15:46 schrieb Dick Hardt : > > I think any scenario with multiple resource servers relying on the same A= S >> for authorization where the client acts on behalf of the resource owner >> qualifies for grant type code and distributed OAuth. >> >> Let=E2=80=99s assume a user wants to authorize a client for access to he= r cloud >> storage, email account and contacts when setting app the respective app. >> > > Would you walk me through the user experience that happened for the clien= t > to do discovery on these three resources? In other words, what did the us= er > do to get the client to call the resource and get back the 401 response? > > > I would assume the user enters the URLs or identifies the respective > service providers in the app (e.g. by entering her email address). The > client then sends an initial request as described in your draft and gets > back the 401. > Entering in an email address that resolves to a resource makes sense. It would seem that even if this was email, calendar etc. -- that those would be different scopes for the same AS, not even different resources. That is how all of Google, Microsoft work today. It seems improbable that an end user is going to post multiple resource end points. But I'm interested if you can present such a use case. > > Doing so for several resources will give the client the AS URL for all > involved resources. If the client compares the iss claims it will figure > our all resources are protected by the same AS and can authorize access v= ia > a single authz code grant flow. > Today, if you had a Google hosted email and a Microsoft hosted email, you would have different AS. Do you have another example? > > kind regards, > Torsten. > --000000000000ae506b05719e64cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 21, 2018 at 12:49 PM, Torsten Lodderstedt <torsten@l= odderstedt.net> wrote:
Hi Dick,

Am 19= .07.2018 um 15:46 schrieb Dick Hardt <dick.hardt@gmail.com>:

I t= hink any scenario with multiple resource servers relying on the same AS for= authorization where the client acts on behalf of the resource owner qualif= ies for grant type code and distributed OAuth.=C2=A0

Let= =E2=80=99s assume a user wants to authorize a client for access to her clou= d storage, email account and contacts when setting app the respective app.<= /div>

Would you walk me through the u= ser experience that happened for the client to do discovery on these three = resources? In other words, what did the user do to get the client to call t= he resource and get back the 401 response?

I would assume the user enters the URLs or identifies th= e respective service providers in the app (e.g. by entering her email addre= ss). The client then sends an initial request as described in your draft an= d gets back the 401.

Entering i= n an email address that resolves to a resource makes sense. It would seem t= hat even if this was email, calendar etc. -- that those would be different = scopes for the same AS, not even different resources. That is how all of Go= ogle, Microsoft work today.

It seems improbable th= at an end user is going to post multiple resource end points. But I'm i= nterested if you can present such a use case.

=C2= =A0

Doing so for several resources will give the client the AS URL for all i= nvolved resources. If the client compares the iss claims it will figure our= all resources are protected by the same AS and can authorize access via a = single authz code grant flow.

T= oday, if you had a Google hosted email and a Microsoft hosted email, you wo= uld have different AS.=C2=A0

Do you have another e= xample?

=C2=A0

kind regards,
Torsten.

--000000000000ae506b05719e64cc-- From nobody Mon Jul 23 00:42:30 2018 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 CD284130E1E for ; Mon, 23 Jul 2018 00:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dYmaXjMSgsGl for ; Mon, 23 Jul 2018 00:42:25 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.99]) (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 E58F212D949 for ; Mon, 23 Jul 2018 00:42:24 -0700 (PDT) Received: from [80.187.100.135] (helo=[10.77.119.75]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fhVU5-0005Cl-K1; Mon, 23 Jul 2018 09:42:22 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-4036E3F1-8D72-4D07-A6A6-0942840AC992; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Mon, 23 Jul 2018 09:42:20 +0200 Cc: oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> To: Dick Hardt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 07:42:28 -0000 --Apple-Mail-4036E3F1-8D72-4D07-A6A6-0942840AC992 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dick, > Am 23.07.2018 um 00:52 schrieb Dick Hardt : >=20 > Entering in an email address that resolves to a resource makes sense. It w= ould seem that even if this was email, calendar etc. -- that those would be d= ifferent scopes for the same AS, not even different resources. That is how a= ll of Google, Microsoft work today. I don=E2=80=99t know how those services work re OAuth resources. To me it=E2= =80=99s not obvious why one should make all those services a single OAuth re= source. I assume the fact OAuth as it is specified today has no concept of i= dentifying a resource and audience restrict an access token led to designs n= ot utilizing audience restriction.=20 Can any of the Google or Microsoft on this list representatives please comme= nt? In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud an= d further services were treated as different resources and clients needed di= fferent (audience restricted) access tokens to use it. In case of YES, the locations of a user=E2=80=99s services for account infor= mation, payment initiation, identity, and electronic signature are determine= d based on her bank affiliation (bank identification code). In general, each= of these services may be provided/operated by a different entity and expose= d at completely different endpoints (even different DNS domains). kind regards, Torsten.= --Apple-Mail-4036E3F1-8D72-4D07-A6A6-0942840AC992 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyMzA3NDIyMFowIwYJKoZIhvcNAQkEMRYE FNrod2EZGeouK6GPuST+7959hLl7MIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQCLdERlzlYwjK4hZP8t0mjB1FS/BMUw VnnIWSUk2cKgXZih4GgbE+cyFjaZrr7km03rlnVuNPPVd3/6gKrcjsdZ8j1EHN2QS3yskXXVAIG5 MtVPniHgcg3Cn/QN4oSBwr1ZUH0gxjkFTST0s4JEBfXhOV+bc/pTn4170LxOf14pU/swFeBeiw0K ruMmiH80jiFohblWEvWwoi78ARtrdzPm99SlqHm488n6mLGSDM1XRTeI9RbOsmgkXiLyHrAui/KX jjCS45iaqdzcotLSmy3Rb6YYWcpzjzfWNhIrqOEIV/BcvsmttygKR3k4FXaQxnx6D9H/MKxcEDrK 7StCmDnNAAAAAAAA --Apple-Mail-4036E3F1-8D72-4D07-A6A6-0942840AC992-- From nobody Mon Jul 23 04:58:25 2018 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 039D0130DE1 for ; Mon, 23 Jul 2018 04:58:23 -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 uLZh7iiaL_Uj for ; Mon, 23 Jul 2018 04:58:21 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::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 5AE71130DD4 for ; Mon, 23 Jul 2018 04:58:21 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id e11-v6so135342plb.3 for ; Mon, 23 Jul 2018 04:58:21 -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=vn8PeUnc21l1ZqBp5fMkzzXcHBTmLLnR7fh+NBmR7xc=; b=UN+Nfid/ZSGtIpGIM+WwhpTHqOxjsBiHDIZQTFosdF69y2aNoeNCxnoR9/1cFfUvLA GfvkpRFoCfCJ8vLV3XZP7D8eklA9nUEhQtXBJbrJF6ezajPg+1jP3R4jdVOKRVnQKWTn hqYvDUz1k4afI/XKogQVxQCCkEyc29BCiN3yer+KeRfSBGAZ+ftcrOhKZppeQWvCgsqF pHuxSxQdJBVVLPOC6yAn7ucMGYTyo1/nT2T9T1VHoXKMnOJj0AlsZfWnFOURkILCVMOS 6VDpHgoXVyqnUheEk3JIedlq7O7gJhJXnpgkWwa0bFqryhPdJ8ZwKjuKdkSiXdqjBE+g wMXQ== 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=vn8PeUnc21l1ZqBp5fMkzzXcHBTmLLnR7fh+NBmR7xc=; b=kY3JBYxgS/piWQxuzbWU1JRdP9VmAzXoWOnaChPRgpzmjshtz6hz5LcHNK9XMYV2Az UeEgcSQrFLuajOtPh0BuywmGHycwRX6TwYsb3rgYSJB9eueB8cdpajDMZJ63Es+7d1Wn 2cgk2mKSEacQJ+bBigfudgbzqZExGYiZVhLk/snvpMeJQe/NKc4Kzi+vrQyJE9AYPXWQ UqizejPfvCtI3dbeoMEk5nmq86mjIIX/FSm02CiRE5yJCa92x5b5ZM/KknnOP0brjVRd 46Uzh+TuutE9SgpaQ7SOUdbbyCATGpyufN/PzrT87zQmJmCg9YtD1ZNVP2UK+8BhF3Gu 4bgA== X-Gm-Message-State: AOUpUlFhviPT2BJ4fO2pQsB8E5f+kyg7sC7eFpQd3g2EFOKgYPSAZXd0 bXqB0h70hE3oJ6Rw4QLSPI7DUjqUbOxHeWJwyVZNJA== X-Google-Smtp-Source: AAOMgpeLrVBQQnYTWMzsYNETZwh6OXWx8yA2vYhTsXY1+ZEVav8PEai5vr8ua8fmDyBKlbsOtGw46DD4Zbt7vX7K0MU= X-Received: by 2002:a17:902:b20d:: with SMTP id t13-v6mr12761863plr.121.1532347100703; Mon, 23 Jul 2018 04:58:20 -0700 (PDT) MIME-Version: 1.0 References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> In-Reply-To: <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> From: Dick Hardt Date: Mon, 23 Jul 2018 07:58:09 -0400 Message-ID: To: Torsten Lodderstedt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000009c309c0571a95c50" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 11:58:23 -0000 --0000000000009c309c0571a95c50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In your examples, are these the same AS? On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt wrote: > Hi Dick, > > > Am 23.07.2018 um 00:52 schrieb Dick Hardt : > > > > Entering in an email address that resolves to a resource makes sense. I= t > would seem that even if this was email, calendar etc. -- that those would > be different scopes for the same AS, not even different resources. That i= s > how all of Google, Microsoft work today. > > I don=E2=80=99t know how those services work re OAuth resources. To me it= =E2=80=99s not > obvious why one should make all those services a single OAuth resource. I > assume the fact OAuth as it is specified today has no concept of > identifying a resource and audience restrict an access token led to desig= ns > not utilizing audience restriction. > > Can any of the Google or Microsoft on this list representatives please > comment? > > In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud= and > further services were treated as different resources and clients needed > different (audience restricted) access tokens to use it. > > In case of YES, the locations of a user=E2=80=99s services for account > information, payment initiation, identity, and electronic signature are > determined based on her bank affiliation (bank identification code). In > general, each of these services may be provided/operated by a different > entity and exposed at completely different endpoints (even different DNS > domains). > > kind regards, > Torsten. --0000000000009c309c0571a95c50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In your examples, are these the same AS?
=



On Mon, Jul 23, 2018 at 3:42 AM Torsten L= odderstedt <torsten@lodderste= dt.net> wrote:
Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Entering in an email address that resolves to a resource makes sense. = It would seem that even if this was email, calendar etc. -- that those woul= d be different scopes for the same AS, not even different resources. That i= s how all of Google, Microsoft work today.

I don=E2=80=99t know how those services work re OAuth resources. To me it= =E2=80=99s not obvious why one should make all those services a single OAut= h resource. I assume the fact OAuth as it is specified today has no concept= of identifying a resource and audience restrict an access token led to des= igns not utilizing audience restriction.

Can any of the Google or Microsoft on this list representatives please comm= ent?

In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud a= nd further services were treated as different resources and clients needed = different (audience restricted) access tokens to use it.

In case of YES, the locations of a user=E2=80=99s services for account info= rmation, payment initiation, identity, and electronic signature are determi= ned based on her bank affiliation (bank identification code). In general, e= ach of these services may be provided/operated by a different entity and ex= posed at completely different endpoints (even different DNS domains).

kind regards,
Torsten.
--0000000000009c309c0571a95c50-- From nobody Mon Jul 23 06:21:05 2018 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 83642130DD0; Mon, 23 Jul 2018 06:20:58 -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.82.0 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, Rifaat Shekh-Yusef , draft-ietf-oauth-token-exchange@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org, Hannes Tschofenig , oauth-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153235205852.20315.16316852302695725778.idtracker@ietfa.amsl.com> Date: Mon, 23 Jul 2018 06:20:58 -0700 Archived-At: Subject: [OAUTH-WG] Last Call: (OAuth 2.0 Token Exchange) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 13:20:59 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Token Exchange' as Proposed Standard 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 2018-08-06. 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 This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jul 23 09:50:31 2018 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 1E66B130EF4 for ; Mon, 23 Jul 2018 09:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.31 X-Spam-Level: X-Spam-Status: No, score=0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=2.899, SPF_PASS=-0.001] autolearn=no 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 P-eMZ-WnuMzD for ; Mon, 23 Jul 2018 09:50:27 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) (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 2E2E0130F1E for ; Mon, 23 Jul 2018 09:50:26 -0700 (PDT) Received: from [80.187.108.225] (helo=[10.50.112.124]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fhe2S-0001qi-CH; Mon, 23 Jul 2018 18:50:24 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-A20BBBF5-5946-4359-B6BC-8C0C275AED25; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Mon, 23 Jul 2018 18:50:23 +0200 Cc: oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> To: Dick Hardt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:50:30 -0000 --Apple-Mail-A20BBBF5-5946-4359-B6BC-8C0C275AED25 Content-Type: multipart/alternative; boundary=Apple-Mail-52370B4F-10B7-4161-9A5D-2FE8C7BB1C9C Content-Transfer-Encoding: 7bit --Apple-Mail-52370B4F-10B7-4161-9A5D-2FE8C7BB1C9C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 23.07.2018 um 13:58 schrieb Dick Hardt : >=20 > In your examples, are these the same AS? yes >=20 >=20 >=20 >> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt wrote: >> Hi Dick, >>=20 >> > Am 23.07.2018 um 00:52 schrieb Dick Hardt : >> >=20 >> > Entering in an email address that resolves to a resource makes sense. I= t would seem that even if this was email, calendar etc. -- that those would b= e different scopes for the same AS, not even different resources. That is ho= w all of Google, Microsoft work today. >>=20 >> I don=E2=80=99t know how those services work re OAuth resources. To me it= =E2=80=99s not obvious why one should make all those services a single OAuth= resource. I assume the fact OAuth as it is specified today has no concept o= f identifying a resource and audience restrict an access token led to design= s not utilizing audience restriction.=20 >>=20 >> Can any of the Google or Microsoft on this list representatives please co= mment? >>=20 >> In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud= and further services were treated as different resources and clients needed= different (audience restricted) access tokens to use it. >>=20 >> In case of YES, the locations of a user=E2=80=99s services for account in= formation, payment initiation, identity, and electronic signature are determ= ined based on her bank affiliation (bank identification code). In general, e= ach of these services may be provided/operated by a different entity and exp= osed at completely different endpoints (even different DNS domains). >>=20 >> kind regards, >> Torsten. --Apple-Mail-52370B4F-10B7-4161-9A5D-2FE8C7BB1C9C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Am 23.07.201= 8 um 13:58 schrieb Dick Hardt <di= ck.hardt@gmail.com>:

In your examples, are these the same AS?

yes




On Mon, Jul 23, 2018 at 3:42 AM Torsten L= odderstedt <torsten@loddersted= t.net> wrote:
Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Entering in an email address that resolves to a resource makes sense. I= t would seem that even if this was email, calendar etc. -- that those would b= e different scopes for the same AS, not even different resources. That is ho= w all of Google, Microsoft work today.

I don=E2=80=99t know how those services work re OAuth resources. To me it=E2= =80=99s not obvious why one should make all those services a single OAuth re= source. I assume the fact OAuth as it is specified today has no concept of i= dentifying a resource and audience restrict an access token led to designs n= ot utilizing audience restriction.

Can any of the Google or Microsoft on this list representatives please comme= nt?

In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud an= d further services were treated as different resources and clients needed di= fferent (audience restricted) access tokens to use it.

In case of YES, the locations of a user=E2=80=99s services for account infor= mation, payment initiation, identity, and electronic signature are determine= d based on her bank affiliation (bank identification code). In general, each= of these services may be provided/operated by a different entity and expose= d at completely different endpoints (even different DNS domains).

kind regards,
Torsten.
= --Apple-Mail-52370B4F-10B7-4161-9A5D-2FE8C7BB1C9C-- --Apple-Mail-A20BBBF5-5946-4359-B6BC-8C0C275AED25 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyMzE2NTAyM1owIwYJKoZIhvcNAQkEMRYE FPkEjL/S3JvgdjwrvOMEjfxZqLsNMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQCmfW59+5B6Q3yh/O4VcoDz3M6YpUa6 NF5CWSBPn2LvYPFdvlegTZZwbyXkv7ofNghAKdC9Oie9QBcUG8DHMgCSmiNOl2mysVfuwNC78AAG oqEIqnsTz7YA3VAQq2paGFGZSEQSb1UyK1XcT+SDL+NNmi9SsW2ydYfnycAvS94koZYGUvd1UJJl aWzUQ805XWYzS7NBQ7ClTfwRU7chx2UPXfUj4CoRBNdOZI17wG/Rq1wCix7MsyREPHoDD9tsEbJe ymZgth+GrD7VU67s03CvK0jPJWRBc2y56/Qh7lFBUd+NN7poIjOTJggAxhRZcDBIK/7mqnDn0JmY 28Iqe8NKAAAAAAAA --Apple-Mail-A20BBBF5-5946-4359-B6BC-8C0C275AED25-- From nobody Mon Jul 23 10:27:06 2018 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 C1C3E130E66 for ; Mon, 23 Jul 2018 10:27:04 -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=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 wh-WRqvFhND6 for ; Mon, 23 Jul 2018 10:27:01 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 4D719130E20 for ; Mon, 23 Jul 2018 10:27:01 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id g11-v6so1191845ioq.9 for ; Mon, 23 Jul 2018 10:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o+A6ysfOT/7ri8Vie0L2AR/Naj+IK/XbcG8mjBTw9ck=; b=ePua8AdIaf6msrQml41UhnxZSQxCx8E1sRX7wn8NeopVQDK29prV+1ocsTvDda4PZp fZfrDB8uptqm3ATAHAUSaXSITCaQifxrrOOrDnO0zJttd0q7m+juugxnlDfr0dEdNXc8 RhdsdC/r1zZjliq9U2I+6mcuHnXNRe6gnHoro= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o+A6ysfOT/7ri8Vie0L2AR/Naj+IK/XbcG8mjBTw9ck=; b=bx9k1o1wZtdJZzMiHigIib5Q4tpt376AaC9lROtYrQVwlhxoVrbi6ZFtNI3TPDnG/d tUKwDbKfz3W+msJortgUyNjxy4Y491jA2DN26dHqElyPNv+QcTjOAC9mZuKW9Zg0r+01 f2X649Ws7RFcRMN7HLWjlMPKdu84DKxbt5b7n9au1B6z26vDDVcgTVqtDSTVwzD6shLw 1/e6KQ/nCJKZaq8SagWLk6B6uIqdbasJvtfsPtzDRFyFRcU7jvxIsnfnbJ0y1Ps+TvaW QVKD/sbvMBsKB8eN0eAL3xlbna5MpqLMr/+kL/8CNhpdB/4KKMZJaQtVNhLBw9DZnJtY 3yMg== X-Gm-Message-State: AOUpUlHfI6QEXft3ry3Qi5AswTFHEFygzWWFWHxYDbyM+59NbVx9hKz+ MPeqaYD8m5MuKnFDeEosfbL3ej7+HpSpT8T+sDxGsvQigYsJvCZM5d5tJwReXwMY+G9h5AKJ6z9 EYZzkVKUiuG3Chg== X-Google-Smtp-Source: AAOMgpd7s0QGyYI9ESTDyNtSLikhk5DEFqadpf4eZYqQBvlNwfc9FdXF32kLq2D25kOrk/xQQZzJdczIJDd1VLTz9VE= X-Received: by 2002:a6b:294b:: with SMTP id p72-v6mr10221228iop.17.1532366820491; Mon, 23 Jul 2018 10:27:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6d18:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 10:26:29 -0700 (PDT) In-Reply-To: <62C4BE6B-5E04-4E93-8083-A6D0895F2740@lodderstedt.net> References: <426DBA0B-CC9B-4D9D-9ED8-5AD779159638@lodderstedt.net> <62C4BE6B-5E04-4E93-8083-A6D0895F2740@lodderstedt.net> From: Brian Campbell Date: Mon, 23 Jul 2018 11:26:29 -0600 Message-ID: To: Torsten Lodderstedt Cc: Filip Skokan , oauth Content-Type: multipart/alternative; boundary="000000000000005d080571adf413" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 17:27:05 -0000 --000000000000005d080571adf413 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My sense is that there's enough WG support to keep the multiple "resource" parameters at both endpoints. The contextual meaning might be a bit different at each endpoint - as you point out the refresh token may represent the overall grant whereas the token request may issue an access token representing the whole or a subset of the overall grant. There's also the implicit grant to consider where the access token is returned from the authorization endpoint. The draft hasn't seen any real changes since the initial -00 individual posting a couple years ago. So, with its impeding adoption, it's overdue for some updates - especially some more text and/or clarifications on what's being discussed in this thread. I'm always happy to consider proposed text from you, Torsten, for any of this stuff. On Sat, Jul 21, 2018 at 10:34 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Brian, > > Am 20.07.2018 um 16:18 schrieb Brian Campbell >: > > The current draft does allow multiple "resource" parameters. However, > there seemed to be consensus in the WG meeting yesterday that only a sing= le > "resource" parameter was preferable > > > I think this makes sense for the token request. This allows the AS to > audience restrict and token bind the access token to a single resource > server URL. > > and that a client could obtain an access token per resource (likely using > a refresh token). > > > I think the refresh token may represent the overall grant whereas the > token request may issue an access token representing the whole or a subse= t > of the overall grant. > > The question is what this means with respect to the scope. I assume scope > values are typically bound to a certain resource service. For example, > =E2=80=9Copenid email mediacloud#read emailservice#read=E2=80=9D would ma= tch to permission > on a OpenID OP, a private cloud and an email service. I therefore would > suggest the AS may filter the scope down to the values applicable to the > resource server for which the access token is being minted. > > Another question relates to the applicable resource URIs. Do you envision > any way to constraint the resource URIs for which an access token might b= e > created for a particular grant? My feeling is the resource owner should > have a chance to consent or not in order to prevent the client to access > resource servers the resource owner does not want it to do so. > > I'm personally sympathetic to that point. But maybe it's too restrictive. > I would like to see some more text about the complexity implications of > multiple "resource" parameters and perhaps some discouragement of doing s= o. > > > As stated above, I=E2=80=99m fine with a single parameter. I could provid= e some > text on how the resource parameter could govern the AS behavior in case o= f > code and refresh token grant. > > I believe logical names are more potentially useful in an STS framework > like token exchange but should be out of scope for this work. > > > Are you referring to logical resource names? > > kind regards, > Torsten. > > > > > > > > > > On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan wrote: > >> Hi Torsten, >> >> > Multiple "resource" parameters may be used to indicate that the issued >> token is intended to be used at multiple resource servers. >> >> That's already in. Furthermore what about logical names for target >> services? Like was added in -03 of token exchange? >> >> Best, >> *Filip Skokan* >> >> >> On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> I support adoption of this document. >>> >>> I would like to point out (again) a single resource is not sufficient >>> for most use cases I implemented in the last couple if years. I=E2=80= =98m >>> advocating for enhancing the draft to support multiple resources and a >>> clear definition of the relationship between resource(s) and scope. >>> >>> Am 20.07.2018 um 08:20 schrieb n-sakimura : >>> >>> +1 >>> >>> >>> >>> *From:* OAuth [mailto:oauth-bounces@ietf.org ] = *On >>> Behalf Of *Brian Campbell >>> *Sent:* Friday, July 20, 2018 7:42 AM >>> *To:* Rifaat Shekh-Yusef >>> *Cc:* oauth >>> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators >>> for OAuth 2.0" >>> >>> >>> >>> I support adoption of this document. >>> >>> >>> >>> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> wrote: >>> >>> Hi all, >>> >>> This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' >>> document >>> following the positive call for adoption at the Montreal IETF meeting. >>> >>> Here is the document: >>> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02 >>> >>> Please let us know by August 2nd whether you accept / object to the >>> adoption of this document as a starting point for work in the OAuth >>> working group. >>> >>> Regards, >>> Rifaat >>> >>> >>> _______________________________________________ >>> 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 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 >> >> > > *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._ --000000000000005d080571adf413 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My sense is that there's enough WG support to kee= p the multiple "r= esource" parameters at both endpoints. The contextual meaning m= ight be a bit different at each endpoint - as you point out the refresh tok= en may represent the overall grant whereas the token=20 request may issue an access token representing the whole or a subset of=20 the overall grant. There's also the implicit grant to consider where th= e access token is returned from the authorization endpoint.
=
The draft hasn't seen any real changes since the initial= -00 individual posting a couple years ago.=C2=A0 So, with its impeding ado= ption, it's overdue for some updates - especially some more text and/or= clarifications on what's being discussed in this thread. I'm alway= s happy to consider proposed text from you, Torsten, for any of this stuff.= =C2=A0



On Sat, Jul 21, 2018 at 10:34 AM, Torst= en Lodderstedt <torsten@lodderstedt.net> wrote:
=
Hi Brian,

Am 20.07.2018 um 1= 6:18 schrieb Brian Campbell <bcampbell@pingidentity.com>:

The current draft does allo= w multiple "resource" parameters. However, there seemed to be con= sensus in the WG meeting yesterday that only a single "resource" = parameter was preferable

I think this makes sense for the token request. This allows the AS = to audience restrict and token bind the access token to a single resource s= erver URL.

and that a client could obtain an access token per resource = (likely using a refresh token).

I think the refresh token may represent the overall grant wh= ereas the token request may issue an access token representing the whole or= a subset of the overall grant.

The question is wh= at this means with respect to the scope. I assume scope values are typicall= y bound to a certain resource service. For example, =E2=80=9Copenid email m= ediacloud#read emailservice#read=E2=80=9D would match to permission on a Op= enID OP, a private cloud and an email service. I therefore would suggest th= e AS may filter the scope down to the values applicable to the resource ser= ver for which the access token is being minted.

An= other question relates to the applicable resource URIs. Do you envision any= way to constraint the resource URIs for which an access token might be cre= ated for a particular grant? My feeling is the resource owner should have a= chance to consent or not in order to prevent the client to access resource= servers the resource owner does not want it to do so.

I'= ;m personally sympathetic to that point. But maybe it's too restrictive= . I would like to see some more text about the complexity implications of m= ultiple "resource" parameters and perhaps some discouragement of = doing so.

As stat= ed above, I=E2=80=99m fine with a single parameter. I could provide some te= xt on how the resource parameter could govern the AS behavior in case of co= de and refresh token grant.

I believe logical names are more potentiall= y useful in an STS framework like token=C2=A0exchange but should be out of = scope for this work.

A= re you referring to logical resource names?

kind regards= ,
Torsten.

=C2=A0





<= div class=3D"gmail_extra">
On Fri, Jul 20, 20= 18 at 3:43 AM, Filip Skokan <panva.ip@gmail.com> wrote:
=
Hi Torsten,
=
>=C2=A0Multiple "resource" parameters may be us= ed to indicate that the issued token is intended to be used at multiple res= ource servers.

That's already in. Furthermore = what about logical names for target services? Like was added in -03 of toke= n exchange?

Best,
Filip Skokan


On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt <torsten@lodderstedt.net&g= t; wrote:
I support adoption of this document.

I wo= uld like to point out (again) a single resource is not sufficient for most = use cases I implemented in the last couple if years. I=E2=80=98m advocating= for enhancing the draft to support multiple resources and a clear definiti= on of the relationship between resource(s) and scope.

Am 20.0= 7.2018 um 08:20 schrieb n-sakimura <n-sakimura@nri.co.jp>:

+1

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On B= ehalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicat= ors for OAuth 2.0"

=C2=A0

I support adoption of this document. <= /p>

=C2=A0

On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef = <rifaat.ietf@= gmail.com> wrote:

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0= ' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat


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

=C2=A0


CONFIDENTIAL= ITY 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..=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 attach= ments from your computer. Thank you.

___________________= ____________________________
OAuth mailing list=
OAuth@ietf.or= g
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



CONFIDENTIALITY NOTICE: This email may contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited.=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le 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. --000000000000005d080571adf413-- From nobody Mon Jul 23 16:25:35 2018 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 9A2CD130E04 for ; Mon, 23 Jul 2018 16:25:33 -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 WFSiIB4f0T1c for ; Mon, 23 Jul 2018 16:25:31 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (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 8CD15130DF1 for ; Mon, 23 Jul 2018 16:25:31 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id o7-v6so861829plk.10 for ; Mon, 23 Jul 2018 16:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7QM/AkoCuFMHzD2BNbxOCzzAGFriehj9yxt+2ds0OIw=; b=XvRSkIr/2s0eVwqvJvR2CW/yXCF48+IpQG2GuymbZsaPasrdu6MjywLbTHssE2sB/c 8m4ch5XG2LeAvHdRZ2qwv3aEUGzsT9BbJk/3V6n/GXPiAcVGGKcrtT2vcXNqIWEVcaZj PD9dMQFFEOXvHm9Eq/YylRUJd30PPhDg8ULMzAQZ4hEsfsxINIdKApnWqXxol3NChqJa lIdo+XNaRSmEfRcdCoOfeLYmdtO6e5GKvckLy04PTSrBi/0YwhqfUgQXQggLb1YF8CDw HkXrRXGV1L1gpCcsozQ2fDpl749o26+Tqlrddal0a6xkgaD8NJQs1TCACHnefpScO+Em g1AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7QM/AkoCuFMHzD2BNbxOCzzAGFriehj9yxt+2ds0OIw=; b=WkKrI9nP1UAzTT7ci/xoy0Fmr1T1J0l8SOdhPUM4bnGGK9g5PV5whWqwJ/5l3GKM/+ 7VAC72utR0g2gfDaPdU5HANBrgOpDwK+SoSLYWnAPMBKtVmqnKJJAPGOM0eZ8UHhvpNp w537NKVZQEbEDRGF9ogNWKNQqajB3IKQwFja65MnWfywmQUOmQdIsmN90fDXPTVnvd9d tQqvE4/onHYtaVNBC8cbUQUCWXd0hgDZcuKQ42gpCIDgX0mAbXofr7Eth0lK1wcVXBlM cTXa08QAOaIRhlk9EfVpRfSxrYoV/bBlR1Npd/pZLhG3+7cHuopuReJYjyaZCh9AVzvs TAPg== X-Gm-Message-State: AOUpUlFBETsAr0/a93xQVSaCzVJUpi+N0M0qO9TQI5mvWISOT3LX7+5c SUV82LIkoiQL30mZB0AZ+8bisDiFL0QZM/tbopHDRg== X-Google-Smtp-Source: AAOMgpe0WFu5HeSmdrwYPhx+PjwDIas8ClxTgxNzm9qmbXEye+H/kZWczKCqKg7xUNszbkSgE9LqTMSBhIOTR8ytG7o= X-Received: by 2002:a17:902:b20d:: with SMTP id t13-v6mr14811969plr.121.1532388330902; Mon, 23 Jul 2018 16:25:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:150c:0:0:0:0 with HTTP; Mon, 23 Jul 2018 16:25:09 -0700 (PDT) In-Reply-To: <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> From: Dick Hardt Date: Mon, 23 Jul 2018 19:25:09 -0400 Message-ID: To: Torsten Lodderstedt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000001f1c7f0571b2f68a" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 23:25:34 -0000 --0000000000001f1c7f0571b2f68a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And who is the AS? On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > > Am 23.07.2018 um 13:58 schrieb Dick Hardt : > > In your examples, are these the same AS? > > > yes > > > > > On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Dick, >> >> > Am 23.07.2018 um 00:52 schrieb Dick Hardt : >> > >> > Entering in an email address that resolves to a resource makes sense. >> It would seem that even if this was email, calendar etc. -- that those >> would be different scopes for the same AS, not even different resources. >> That is how all of Google, Microsoft work today. >> >> I don=E2=80=99t know how those services work re OAuth resources. To me i= t=E2=80=99s not >> obvious why one should make all those services a single OAuth resource. = I >> assume the fact OAuth as it is specified today has no concept of >> identifying a resource and audience restrict an access token led to desi= gns >> not utilizing audience restriction. >> >> Can any of the Google or Microsoft on this list representatives please >> comment? >> >> In deployments I=E2=80=98m familiar with email, calendar, contacts, clou= d and >> further services were treated as different resources and clients needed >> different (audience restricted) access tokens to use it. >> >> In case of YES, the locations of a user=E2=80=99s services for account >> information, payment initiation, identity, and electronic signature are >> determined based on her bank affiliation (bank identification code). In >> general, each of these services may be provided/operated by a different >> entity and exposed at completely different endpoints (even different DNS >> domains). >> >> kind regards, >> Torsten. > > --0000000000001f1c7f0571b2f68a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And who is the AS?

On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderste= dt <torsten@lodderstedt.net> wrote:

Am 23.07.2018 um 13:58 schrieb Dick Hardt <dick.hardt@gmail.com>:

<= /div>
In your examples= , are these the same AS?

yes




On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderst= edt <torste= n@lodderstedt.net> wrote:
Hi= Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Entering in an email address that resolves to a resource makes sense. = It would seem that even if this was email, calendar etc. -- that those woul= d be different scopes for the same AS, not even different resources. That i= s how all of Google, Microsoft work today.

I don=E2=80=99t know how those services work re OAuth resources. To me it= =E2=80=99s not obvious why one should make all those services a single OAut= h resource. I assume the fact OAuth as it is specified today has no concept= of identifying a resource and audience restrict an access token led to des= igns not utilizing audience restriction.

Can any of the Google or Microsoft on this list representatives please comm= ent?

In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud a= nd further services were treated as different resources and clients needed = different (audience restricted) access tokens to use it.

In case of YES, the locations of a user=E2=80=99s services for account info= rmation, payment initiation, identity, and electronic signature are determi= ned based on her bank affiliation (bank identification code). In general, e= ach of these services may be provided/operated by a different entity and ex= posed at completely different endpoints (even different DNS domains).

kind regards,
Torsten.

--0000000000001f1c7f0571b2f68a-- From nobody Tue Jul 24 06:31:59 2018 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 94672131110; Tue, 24 Jul 2018 06:31:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153243911759.22454.13623930642678414831.idtracker@ietfa.amsl.com> Date: Tue, 24 Jul 2018 06:31:57 -0700 Archived-At: Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 13:31:58 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-device-flow-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Let me preface this by noting that I'm not sure that all of these points are actionable; I would, however, like to discuss them. I'm really unhappy to not see any hard numbers on the entropy needed in a user code to provide a reasonable security margin with given parameters, and how it compares to the guessability bounds considered best practices in general (across protocols). For example, we think 128-bit symmetric keys are okay because an attacker has to put in 2**96 work to have a 2**-32 chance of guessing correctly via brute force; the rate limiting and finite lifetime on the user code places an artificial limit on the amount of work an attacker can "do", so if one uses a 8-character base-20 user code (with roughly 34.5 bits of entropy), the rate-limiting interval and validity period would need to only allow 5 attempts in order to get the same 2**-32 probability of success by random guessing. Section 5.1 would be a great place for such text, near the preexisting: The user code SHOULD have enough entropy that when combined with rate limiting and other mitigations makes a brute-force attack infeasible. We talk about "the authorization server", but any given *user* may have a relationship with multiple such ASes. Can the Introduction make it more clear that the AS is associated with the device/client, and as such the it may not be the user's most-trusted AS? It also seems like a large latent risk with this flow is when the verification_uri_complete response is used along with an AS that assumes an authenticated user making such a verification request has approved the authorization (i.e., without an explicit user interaction to confirm), when that AS uses cookies or other persistent state to keep the user authenticated across multiple requests. I could not find any MUST-level requirement for user interaction to confirm the device being authorized (even in Section 3.3, which covers the regular verificat_uri workflow!); please let me know if I missed something. I would like to see some explicit text that (matching the flow described in Section 3.1 that requires the user to input the code) explicit user approval of the authorization is required. (I do note that Section 5.3 has text about "SHOULD display information about the device.) I'm also unhappy about the text in Section 1 that merely requires of the device the ability to "make outbound HTTPS requests", which leaves room for an awful lot of sins in certificate validation (and, potentially, ciphersuite selection). Can we get a MUST-level requirement for authenticating the server and a cite to RFC 7525? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please use the RFC 8174 boilerplate instead of the RFC 2119 one. Section 3.2 The example expires in 30 minutes? That seems longer than needed; wouldn't 5 minutes do? Section 3.3 I agree with directorate reviewer that the MUST NOT requirement for displaying the device_code should justify that requirement by discussing the consequences of exposure. Section 3.5 authorization_pending The authorization request is still pending as the end-user hasn't yet completed the user interaction steps (Section 3.3). The client should repeat the Access Token Request to the token endpoint. I feel like we want to mention the 'interval' here or some other discussion of an inter-request delay. Also, please clarify "reasonable default polling interval", per multiple directorate reviews. Section 5.2 Please clarify the entities involved in "the backchannel flow" that can be MITM'd. Section 5.6 The "short-range" part of a "short-range wireless signal" partially depends on how big the receiver's antenna is. So perhaps we should be careful about indicating that this has more security value than it does. Section 6.1 I'm not sure I understand the usage of "case-insensitive", here -- how would the user have an expectation of case-insensitivity? Perhaps it is better to just say "majuscule" or "upper case" or whatever. From nobody Tue Jul 24 08:59:39 2018 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 741F0130DF5 for ; Tue, 24 Jul 2018 08:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cr6wrpOhlUZR for ; Tue, 24 Jul 2018 08:59:35 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (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 EA02D130D7A for ; Tue, 24 Jul 2018 08:59:34 -0700 (PDT) Received: from [80.187.99.185] (helo=[10.154.68.6]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fhzim-0005eu-68; Tue, 24 Jul 2018 17:59:32 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-0440DDE9-001F-40DF-8355-2ADB7B5D4C2E; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Tue, 24 Jul 2018 17:59:29 +0200 Cc: oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> To: Dick Hardt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 15:59:39 -0000 --Apple-Mail-0440DDE9-001F-40DF-8355-2ADB7B5D4C2E Content-Type: multipart/alternative; boundary=Apple-Mail-75069959-3917-4D9F-B2EF-AC9F05A2BE6F Content-Transfer-Encoding: 7bit --Apple-Mail-75069959-3917-4D9F-B2EF-AC9F05A2BE6F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > And who is the AS? In case of yes, it=E2=80=99s typically the bank. At Deutsche Telekom, it is t= he central AS/IDP.=20 Why are you asking? >=20 >> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt wrote: >>=20 >>> Am 23.07.2018 um 13:58 schrieb Dick Hardt : >>>=20 >>> In your examples, are these the same AS? >>=20 >> yes >>=20 >>>=20 >>>=20 >>>=20 >>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt wrote: >>>> Hi Dick, >>>>=20 >>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt : >>>> >=20 >>>> > Entering in an email address that resolves to a resource makes sense.= It would seem that even if this was email, calendar etc. -- that those woul= d be different scopes for the same AS, not even different resources. That is= how all of Google, Microsoft work today. >>>>=20 >>>> I don=E2=80=99t know how those services work re OAuth resources. To me i= t=E2=80=99s not obvious why one should make all those services a single OAut= h resource. I assume the fact OAuth as it is specified today has no concept o= f identifying a resource and audience restrict an access token led to design= s not utilizing audience restriction.=20 >>>>=20 >>>> Can any of the Google or Microsoft on this list representatives please c= omment? >>>>=20 >>>> In deployments I=E2=80=98m familiar with email, calendar, contacts, clo= ud and further services were treated as different resources and clients need= ed different (audience restricted) access tokens to use it. >>>>=20 >>>> In case of YES, the locations of a user=E2=80=99s services for account i= nformation, payment initiation, identity, and electronic signature are deter= mined based on her bank affiliation (bank identification code). In general, e= ach of these services may be provided/operated by a different entity and exp= osed at completely different endpoints (even different DNS domains). >>>>=20 >>>> kind regards, >>>> Torsten. >=20 --Apple-Mail-75069959-3917-4D9F-B2EF-AC9F05A2BE6F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

And who is the AS?

In case of yes, it=E2=80=99s typically the bank. At Deutsche Tele= kom, it is the central AS/IDP. 

Why are you asking?<= br>

<= br>
On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodd= erstedt <torsten@lodderstedt.net> wrote:

Am 23.07.2018 um 13:58 schrieb Dick Hardt <dick.hardt@gmail.com>:

In your examples, ar= e these the same AS?

yes




On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <= torsten@lodders= tedt.net> wrote:
Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Entering in an email address that resolves to a resource makes sense. I= t would seem that even if this was email, calendar etc. -- that those would b= e different scopes for the same AS, not even different resources. That is ho= w all of Google, Microsoft work today.

I don=E2=80=99t know how those services work re OAuth resources. To me it=E2= =80=99s not obvious why one should make all those services a single OAuth re= source. I assume the fact OAuth as it is specified today has no concept of i= dentifying a resource and audience restrict an access token led to designs n= ot utilizing audience restriction.

Can any of the Google or Microsoft on this list representatives please comme= nt?

In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud an= d further services were treated as different resources and clients needed di= fferent (audience restricted) access tokens to use it.

In case of YES, the locations of a user=E2=80=99s services for account infor= mation, payment initiation, identity, and electronic signature are determine= d based on her bank affiliation (bank identification code). In general, each= of these services may be provided/operated by a different entity and expose= d at completely different endpoints (even different DNS domains).

kind regards,
Torsten.

= --Apple-Mail-75069959-3917-4D9F-B2EF-AC9F05A2BE6F-- --Apple-Mail-0440DDE9-001F-40DF-8355-2ADB7B5D4C2E Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyNDE1NTkyOVowIwYJKoZIhvcNAQkEMRYE FNv/yMz6ZoEZlP/2X91a2uQFSk/GMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQCJqIc542oU7s5/xb3cBkFKbx8pSMzF Y5EpTr+yz9gI+D9/RDT3Zt4j7n5Hrnia6frQsUi2fiTTo90uSF/p2InHNH1g7vVWD7PtuF2fIOtX /b5mLUx/H84B54+IIFx+ePizRgKTs1iFEQsYmFk0Y3vO4OnpQAaap0WFChkB/yyvbz6XRR2NNBDT F8f43B4PAd29P75hqUIx0OIowItnaYLLIVSg4apMcyKd0vg0maMB5/gJjxTQ/UZzy3JwdRdRq0t7 KjbF4Vn0O1ILAglBWfgxhySgYZ3Kv3MntdXU/7C1l0TD2tFyBkQXRfee5X5pdQJd7nljmO98v85d YlWMa4GIAAAAAAAA --Apple-Mail-0440DDE9-001F-40DF-8355-2ADB7B5D4C2E-- From nobody Tue Jul 24 11:51:10 2018 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 945A1130F1C; Tue, 24 Jul 2018 11:50:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153245825559.22685.11395607099141261021.idtracker@ietfa.amsl.com> Date: Tue, 24 Jul 2018 11:50:55 -0700 Archived-At: Subject: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-i?= =?utf-8?q?etf-oauth-device-flow-11=3A_=28with_DISCUSS=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:50:56 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-oauth-device-flow-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Please specify more clearly the (default) polling behavior to ensure that the polling does neither overload the network, nor the server, or is never terminated. Ideally provide default values and an upper bound for the polling frequency, as well as a timer to terminate polling if no reply is received (and no expiration time is given). See further details below. 1) Sec 3.3: "until the user completes the interaction, the code expires, or another error occurs." What if not expiration time is given (as this optional) and no reply is ever received? 2) Sec 3.5: "the client should stop polling and react accordingly, for example, by displaying an error to the user." Maybe: "the client MUST stop polling and SHOULD react accordingly, for example, by displaying an error to the user." 3) sec 3.5 "If no interval was provided, the client MUST use a reasonable default polling interval." Can you please provide a default number for a "reasonable" polling interval! And in best case an upper bound! 4) sec 3.5: "...increasing the time between polls if a "slow_down" error is received. " Maybe use a separate normative sentence instead: "The client SHOUD increase the time between polls if a "slow_down" error is received." Or MUST? If so how much? Can you given further (default) guidance. 5) sec 3.5: "Clients MAY then choose to start a new device authorization session." Maybe make it clear that polling is stopped "Clients MUST stop polling but MAY then choose to start a new device authorization session." 6) sec 3.5: "then the device MAY wait until notified on that channel that the user has completed the action before initiating the token request." Why not SHOULD (or MUST) here? From nobody Tue Jul 24 13:21:41 2018 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 C9412130DE4 for ; Tue, 24 Jul 2018 13:21:39 -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 Jloi4XW5KW4v for ; Tue, 24 Jul 2018 13:21:38 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 16EE4130E02 for ; Tue, 24 Jul 2018 13:21:38 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id v13-v6so3650569pgr.10 for ; Tue, 24 Jul 2018 13:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FB2yLYLjrjNGqpg8spxK+abZ8/4BZ/qabdQdMNJfMDE=; b=Oukmxw5ie7l4S3fOKZrIYvqlGBOshoV7yRRt6mp2UqEyLr94TTy1emX/IfOIdNIRJ0 RNbvewLdf0gPZq8Bpkb3sMo0EfBq/hR0KyNPDfby55j5sQoTelWnp3w18YaAZq+bwYfr CAJ6pbdDU+iFs6xurdQOaPO/8NPnPDhEamM5ofytiHqBu1zx/iauJjDJhn30aNHNl5lO 9bGPFxZzZJgJMb29c+2OOb0cPoJhMNCjZ6M65dpvdQmTS3faxxeuG67mGufG3HSQqMud PMZ75eZ3Rvz79H5vKF6vO16R6MWjluArl2TUu4jL+DrHQFvErW5ImZv2brrpxW9HpSAG ka7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FB2yLYLjrjNGqpg8spxK+abZ8/4BZ/qabdQdMNJfMDE=; b=dgow3YZKe5W5/DDK1jH+ntInjOIMiWHR9PYQMrGAkHk912t576A5L6yYnEJO9+lbrr a9Sk7sFqcQzqVHdWz7XyYN9bkod6e5Rlh9SEBh8ItPIU1rHD5Fm5G3eYcD3KPnP/ALUf oDrVIzF7JUtd7/tj0o7nvGY9bnm6WnJZeRTTQLiiy7OAWAdVnVe4fhI1S8HLt3dBzrxC 5l2y/uCmf3N0VmaFeRzZtj3OHCPCpnnhZAf7gqUEEPQDQSUokhSgAqijjyy1ZKxHchEa zNE1VKovJ58onFHUkvirsxhGP/Fl+c/5jEl/imhGNljKZ+2ONtHftp4YMIyzINIkyhPG wIbA== X-Gm-Message-State: AOUpUlEozH1Ah1GCBsfQGPU8DGtb7WFWXSC1PnerhgLNxivGSzrSDg4y RK78J7fmCsqciXxpjBhKrV0zjJhB/xIC1z0Joea0yvon X-Google-Smtp-Source: AAOMgpfSPvYsReOJZx7ASmbSrLy+bLNT9pLdQkP1ThP6zsnPlCZxv93WOr/n/AL0JOMtGmD0NJiiWNe3IFnJlb7qZmc= X-Received: by 2002:aa7:84c2:: with SMTP id x2-v6mr18996808pfn.220.1532463697507; Tue, 24 Jul 2018 13:21:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Tue, 24 Jul 2018 13:21:17 -0700 (PDT) In-Reply-To: References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> From: Dick Hardt Date: Tue, 24 Jul 2018 13:21:17 -0700 Message-ID: To: Torsten Lodderstedt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000523b890571c4823a" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:21:40 -0000 --000000000000523b890571c4823a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm trying to understand the use case. It still is vague. Are you saying that each of these is run by a different entity, but all trust the bank as the authorization server to manage if the user has granted permission to use the resource rather than managing it themselves? account information, payment initiation, identity, and electronic signature On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > > And who is the AS? > > > In case of yes, it=E2=80=99s typically the bank. At Deutsche Telekom, it = is the > central AS/IDP. > > Why are you asking? > > > On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> >> Am 23.07.2018 um 13:58 schrieb Dick Hardt : >> >> In your examples, are these the same AS? >> >> >> yes >> >> >> >> >> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> Hi Dick, >>> >>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt : >>> > >>> > Entering in an email address that resolves to a resource makes sense. >>> It would seem that even if this was email, calendar etc. -- that those >>> would be different scopes for the same AS, not even different resources= . >>> That is how all of Google, Microsoft work today. >>> >>> I don=E2=80=99t know how those services work re OAuth resources. To me = it=E2=80=99s not >>> obvious why one should make all those services a single OAuth resource.= I >>> assume the fact OAuth as it is specified today has no concept of >>> identifying a resource and audience restrict an access token led to des= igns >>> not utilizing audience restriction. >>> >>> Can any of the Google or Microsoft on this list representatives please >>> comment? >>> >>> In deployments I=E2=80=98m familiar with email, calendar, contacts, clo= ud and >>> further services were treated as different resources and clients needed >>> different (audience restricted) access tokens to use it. >>> >>> In case of YES, the locations of a user=E2=80=99s services for account >>> information, payment initiation, identity, and electronic signature are >>> determined based on her bank affiliation (bank identification code). In >>> general, each of these services may be provided/operated by a different >>> entity and exposed at completely different endpoints (even different DN= S >>> domains). >>> >>> kind regards, >>> Torsten. >> >> > --000000000000523b890571c4823a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm trying to understand the use case.=C2=A0

<= /div>
It still is vague. Are you saying that each of these is run by a different entity, bu= t all trust the bank as the authorization server to manage if the user has = granted permission to use the resource rather than managing it themselves?= =C2=A0

account information, payme= nt initiation, identity, and electronic signature=C2=A0

On Tue, Jul 24, 2018 at 8= :59 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

= And who is the AS?

In case of= yes, it=E2=80=99s typically the bank. At Deutsche Telekom, it is the centr= al AS/IDP.=C2=A0

Why are you asking?

On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodd= erstedt <torsten@lodderstedt.net> wrote:

Am 23.07.2018 um 13:58 schrieb Dick Hardt <dick.hardt@gmail.com>:

In your examples, are t= hese the same AS?

= yes




On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <torsten@lodderstedt.net<= /a>> wrote:
Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Entering in an email address that resolves to a resource makes sense. = It would seem that even if this was email, calendar etc. -- that those woul= d be different scopes for the same AS, not even different resources. That i= s how all of Google, Microsoft work today.

I don=E2=80=99t know how those services work re OAuth resources. To me it= =E2=80=99s not obvious why one should make all those services a single OAut= h resource. I assume the fact OAuth as it is specified today has no concept= of identifying a resource and audience restrict an access token led to des= igns not utilizing audience restriction.

Can any of the Google or Microsoft on this list representatives please comm= ent?

In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud a= nd further services were treated as different resources and clients needed = different (audience restricted) access tokens to use it.

In case of YES, the locations of a user=E2=80=99s services for account info= rmation, payment initiation, identity, and electronic signature are determi= ned based on her bank affiliation (bank identification code). In general, e= ach of these services may be provided/operated by a different entity and ex= posed at completely different endpoints (even different DNS domains).

kind regards,
Torsten.


--000000000000523b890571c4823a-- From nobody Tue Jul 24 13:47:17 2018 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 4A8D0130DEA for ; Tue, 24 Jul 2018 13:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 v9p03Vo5o4lF for ; Tue, 24 Jul 2018 13:47:11 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) (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 8EE4D1277C8 for ; Tue, 24 Jul 2018 13:47:11 -0700 (PDT) Received: from [84.158.238.150] (helo=[192.168.71.112]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fi4D6-0004iB-Nh; Tue, 24 Jul 2018 22:47:08 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-E83E1D74-1EE1-42D2-B87D-78C2FC810970; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Tue, 24 Jul 2018 22:47:07 +0200 Cc: oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> To: Dick Hardt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:47:16 -0000 --Apple-Mail-E83E1D74-1EE1-42D2-B87D-78C2FC810970 Content-Type: multipart/alternative; boundary=Apple-Mail-22620CA6-9570-42F4-B73A-40193FF5E48A Content-Transfer-Encoding: 7bit --Apple-Mail-22620CA6-9570-42F4-B73A-40193FF5E48A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For every bank (and their customers) there is a set of services run by the b= ank or other entities, which rely on the AS of the particular bank for autho= rization. In some cases, a service may bring its own AS to the party (due to= technical restrictionions). So an RP binding to a certain bank-specific ser= vice ecosystem needs to determine which AS every RS relies on. Authorization= requests for RS relying on the same AS (the bank) can be combined into s si= ngle request/flow resulting in an optimized UX. > Am 24.07.2018 um 22:21 schrieb Dick Hardt : >=20 > I'm trying to understand the use case.=20 >=20 > It still is vague. Are you saying that each of these is run by a different= entity, but all trust the bank as the authorization server to manage if the= user has granted permission to use the resource rather than managing it the= mselves?=20 >=20 > account information, payment initiation, identity, and electronic signatur= e=20 >=20 >> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt wrote: >>=20 >>> And who is the AS? >>=20 >> In case of yes, it=E2=80=99s typically the bank. At Deutsche Telekom, it i= s the central AS/IDP.=20 >>=20 >> Why are you asking? >>=20 >>>=20 >>>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt wrote: >>>>=20 >>>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt : >>>>>=20 >>>>> In your examples, are these the same AS? >>>>=20 >>>> yes >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt wrote: >>>>>> Hi Dick, >>>>>>=20 >>>>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt : >>>>>> >=20 >>>>>> > Entering in an email address that resolves to a resource makes sens= e. It would seem that even if this was email, calendar etc. -- that those wo= uld be different scopes for the same AS, not even different resources. That i= s how all of Google, Microsoft work today. >>>>>>=20 >>>>>> I don=E2=80=99t know how those services work re OAuth resources. To m= e it=E2=80=99s not obvious why one should make all those services a single O= Auth resource. I assume the fact OAuth as it is specified today has no conce= pt of identifying a resource and audience restrict an access token led to de= signs not utilizing audience restriction.=20 >>>>>>=20 >>>>>> Can any of the Google or Microsoft on this list representatives pleas= e comment? >>>>>>=20 >>>>>> In deployments I=E2=80=98m familiar with email, calendar, contacts, c= loud and further services were treated as different resources and clients ne= eded different (audience restricted) access tokens to use it. >>>>>>=20 >>>>>> In case of YES, the locations of a user=E2=80=99s services for accoun= t information, payment initiation, identity, and electronic signature are de= termined based on her bank affiliation (bank identification code). In genera= l, each of these services may be provided/operated by a different entity and= exposed at completely different endpoints (even different DNS domains). >>>>>>=20 >>>>>> kind regards, >>>>>> Torsten. >>>=20 >=20 --Apple-Mail-22620CA6-9570-42F4-B73A-40193FF5E48A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
For every bank (and their c= ustomers) there is a set of services run by the bank or other entities, whic= h rely on the AS of the particular bank for authorization. In some cases, a s= ervice may bring its own AS to the party (due to technical restrictionions).= So an RP binding to a certain bank-specific service ecosystem needs to dete= rmine which AS every RS relies on. Authorization requests for RS relying on t= he same AS (the bank) can be combined into s single request/flow resulting i= n an optimized UX.

Am 24.07.2018 um 22:21 schrieb Dick Hardt &= lt;dick.hardt@gmail.com>:
=
I'm trying to unde= rstand the use case. 

It still is vague. Are you say= ing that each of these is run by a different entity, but all trust the bank as the authorization s= erver to manage if the user has granted permission to use the resource rathe= r than managing it themselves? 

account information, payment initiation, identity, and electronic signature=  

O= n Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt <torsten@lodderste= dt.net> wrote:

And who is the AS?

In case of yes, it=E2=80=99s typically the bank. At Deutsche Telekom= , it is the central AS/IDP. 

Why are you asking?


On Mon, Jul 23, 2018 at 12:50 PM= , Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=
Am 23.07.2018 um 13:58 schrieb Dick Hardt <dick.hardt@gmail.com>:

=
In your examples= , are these the same AS?

yes



On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <torsten@lodderstedt.ne= t> wrote:
Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Entering in an email address that resolves to a resource makes sense. I= t would seem that even if this was email, calendar etc. -- that those would b= e different scopes for the same AS, not even different resources. That is ho= w all of Google, Microsoft work today.

I don=E2=80=99t know how those services work re OAuth resources. To me it=E2= =80=99s not obvious why one should make all those services a single OAuth re= source. I assume the fact OAuth as it is specified today has no concept of i= dentifying a resource and audience restrict an access token led to designs n= ot utilizing audience restriction.

Can any of the Google or Microsoft on this list representatives please comme= nt?

In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud an= d further services were treated as different resources and clients needed di= fferent (audience restricted) access tokens to use it.

In case of YES, the locations of a user=E2=80=99s services for account infor= mation, payment initiation, identity, and electronic signature are determine= d based on her bank affiliation (bank identification code). In general, each= of these services may be provided/operated by a different entity and expose= d at completely different endpoints (even different DNS domains).

kind regards,
Torsten.


= --Apple-Mail-22620CA6-9570-42F4-B73A-40193FF5E48A-- --Apple-Mail-E83E1D74-1EE1-42D2-B87D-78C2FC810970 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyNDIwNDcwN1owIwYJKoZIhvcNAQkEMRYE FMHCsumItFgxSvSmSk/xKSj5DhyeMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQAhSKmmmN4ehkBBfbFnw5AzinN8Vurj JXOjoF5s/4tsGWy8Tvp7NTMLeAwhlbsyq+yzFs6JRlLF05THi/lrYpY22QTjwFeIaKpZW1Lvj4sL o05IoflkSOIjt0QLPbOJjSQt+ZM3UGOGPz1UK5kHt2vClE0lRzYE1dMx19jq0bDvxSDSYY+32xRd uWs1nZBAYYJSKnHLwUSkBh7JDdeYu43DNshOitEuSG1BUwHyzrRERDhZbSO6pprb2eR43QJcxYMD X4BRoZlG7wCD5BVF4QNCcx/E/6XfNRADC4HTApxHJKYk9qs7dQrNdkKNEFz3JqVJXy4pcP7VfoTm P+q7EJwMAAAAAAAA --Apple-Mail-E83E1D74-1EE1-42D2-B87D-78C2FC810970-- From nobody Tue Jul 24 13:52:12 2018 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 8E114130EC7 for ; Tue, 24 Jul 2018 13:52:10 -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 AckctaywY4G3 for ; Tue, 24 Jul 2018 13:52:07 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 C662D130EE2 for ; Tue, 24 Jul 2018 13:52:07 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id y4-v6so3697126pgp.9 for ; Tue, 24 Jul 2018 13:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3SLuOBpxIxFTGQMzw1OXsIXvI5LgqdyA7esSjhQSl0s=; b=Igrscd02T251iSfH6a8x0CoMcrtPohnpYTS2fE5RDnBcvqRDCCXWkiN3TrDhzE/O7B X5fWh6Zh7nbeuXso2eKBQuM1t/XjKDsEGkVzLJDzzaz8lQuCNeaprCoaFDmtD0apRLUu buFTOD9giuHPeoiDC+od7yw3BsyG0x1QKyJCXMP9MZuM5xnnByMJE+tbUktZITcLPVp+ ahzRKBpGesFVpAZdVdnPp31GXAXSdG3vKTbl/w1ONAabJVsfngH+rh3rTKYZo4sUKf6v iiiiYF9LmfqFqqNBOfy/G2X2f1JQ2x9kMayxWIOnxlM2Ih+TjzSFg8iI9Jb5f8aOHili fjtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3SLuOBpxIxFTGQMzw1OXsIXvI5LgqdyA7esSjhQSl0s=; b=foO+d7smXnQ149VAhm8qGzajyBaL9gty/DFWwexzUlkvl64j4hbm9WJcxSc85j74am r3b6xsPQbfJn+cKGv2aE57rW6OWbIe7Sz363Tek6LRCfMENFcWRo6YBmEgmXc8qq6uDr K3gNeDaOzffmHPkCWd1XcgZODoaYGbBmB76rP0iYJ9f+pqTy1F6Fwr3aUmHBy91vjhpv bpuq3LweTnAX8zO+Acr3nejoTd5nD1pEED2ltlqN3aqGXkZM3eDRArTzf09oO/h5xaKZ 6n4c8iJBm+AAlRhgi1yunPniPVso+TZ9ibpEl4p5EgYh/mHdJb2RwkAuKCFS30GpcuSX NYKg== X-Gm-Message-State: AOUpUlEP43d6OhmG7coOVal7ZaU8DBnGifMaqVV5+iOj9E04w8yedKnF wQl9nbnAT3PBSh5ln/fOqiIdoNSrVSef8/pvRsFEww== X-Google-Smtp-Source: AAOMgpcNuuHKsQm/ApALsn5+/w0CpB518RWcDxCL2212KXR4ruK4NhdZm1ykQXXpi5KJz1fFbKW9/kp0oKibGqmIq0E= X-Received: by 2002:a62:be03:: with SMTP id l3-v6mr19138364pff.138.1532465527313; Tue, 24 Jul 2018 13:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Tue, 24 Jul 2018 13:51:46 -0700 (PDT) In-Reply-To: References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> From: Dick Hardt Date: Tue, 24 Jul 2018 13:51:46 -0700 Message-ID: To: Torsten Lodderstedt Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000062d92d0571c4efac" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:52:10 -0000 --00000000000062d92d0571c4efac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok. I think I understand the use case now. Would you confirm? These are deployed today, correct? Today, a separate flow us required for each RS, correct? In the future, you would like the client to ask for multiple resources that are managed by the same AS, correct? On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > For every bank (and their customers) there is a set of services run by th= e > bank or other entities, which rely on the AS of the particular bank for > authorization. In some cases, a service may bring its own AS to the party > (due to technical restrictionions). So an RP binding to a certain > bank-specific service ecosystem needs to determine which AS every RS reli= es > on. Authorization requests for RS relying on the same AS (the bank) can b= e > combined into s single request/flow resulting in an optimized UX. > > Am 24.07.2018 um 22:21 schrieb Dick Hardt : > > I'm trying to understand the use case. > > It still is vague. Are you saying that each of these is run by a > different entity, but all trust the bank as the authorization server to > manage if the user has granted permission to use the resource rather than > managing it themselves? > > account information, payment initiation, identity, and electronic signatu= re > > > On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> >> And who is the AS? >> >> >> In case of yes, it=E2=80=99s typically the bank. At Deutsche Telekom, it= is the >> central AS/IDP. >> >> Why are you asking? >> >> >> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> >>> Am 23.07.2018 um 13:58 schrieb Dick Hardt : >>> >>> In your examples, are these the same AS? >>> >>> >>> yes >>> >>> >>> >>> >>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>> Hi Dick, >>>> >>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt : >>>> > >>>> > Entering in an email address that resolves to a resource makes sense= . >>>> It would seem that even if this was email, calendar etc. -- that those >>>> would be different scopes for the same AS, not even different resource= s. >>>> That is how all of Google, Microsoft work today. >>>> >>>> I don=E2=80=99t know how those services work re OAuth resources. To me= it=E2=80=99s not >>>> obvious why one should make all those services a single OAuth resource= . I >>>> assume the fact OAuth as it is specified today has no concept of >>>> identifying a resource and audience restrict an access token led to de= signs >>>> not utilizing audience restriction. >>>> >>>> Can any of the Google or Microsoft on this list representatives please >>>> comment? >>>> >>>> In deployments I=E2=80=98m familiar with email, calendar, contacts, cl= oud and >>>> further services were treated as different resources and clients neede= d >>>> different (audience restricted) access tokens to use it. >>>> >>>> In case of YES, the locations of a user=E2=80=99s services for account >>>> information, payment initiation, identity, and electronic signature ar= e >>>> determined based on her bank affiliation (bank identification code). I= n >>>> general, each of these services may be provided/operated by a differen= t >>>> entity and exposed at completely different endpoints (even different D= NS >>>> domains). >>>> >>>> kind regards, >>>> Torsten. >>> >>> >> > --00000000000062d92d0571c4efac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok. I think I understand the use case now. Would you = confirm?

These are deployed today, correct?

Today, a separate flow us required for each RS, correct?
=
In the future, you would like the client to ask for multiple= resources that are managed by the same AS, correct?


On Tue, Jul 2= 4, 2018 at 1:47 PM, Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:
For every bank (and their customers) there is a set of services= run by the bank or other entities, which rely on the AS of the particular = bank for authorization. In some cases, a service may bring its own AS to th= e party (due to technical restrictionions). So an RP binding to a certain b= ank-specific service ecosystem needs to determine which AS every RS relies = on. Authorization requests for RS relying on the same AS (the bank) can be = combined into s single request/flow resulting in an optimized UX.

Am 24.07.2018 um 22:21 schrieb Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om>:

I&= #39;m trying to understand the use case.=C2=A0

It still = is vague. Are you saying that each of these is run by a different entity, but all trust the ban= k as the authorization server to manage if the user has granted permission = to use the resource rather than managing it themselves?=C2=A0
account information, payment initiation, ident= ity, and electronic signature=C2=A0
<= br>
On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodd= erstedt <torsten@lodderstedt.net> wrote:

And who is the AS?
<= /blockquote>

In case of yes, it=E2=80=99s typically th= e bank. At Deutsche Telekom, it is the central AS/IDP.=C2=A0

=
Why are you asking?

<= div>

On Mon, Jul 2= 3, 2018 at 12:50 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

In your examples, are these the same AS?

yes




On Mon, Jul 23, 2018 at 3:42 AM T= orsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Entering in an email address that resolves to a resource makes sense. = It would seem that even if this was email, calendar etc. -- that those woul= d be different scopes for the same AS, not even different resources. That i= s how all of Google, Microsoft work today.

I don=E2=80=99t know how those services work re OAuth resources. To me it= =E2=80=99s not obvious why one should make all those services a single OAut= h resource. I assume the fact OAuth as it is specified today has no concept= of identifying a resource and audience restrict an access token led to des= igns not utilizing audience restriction.

Can any of the Google or Microsoft on this list representatives please comm= ent?

In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud a= nd further services were treated as different resources and clients needed = different (audience restricted) access tokens to use it.

In case of YES, the locations of a user=E2=80=99s services for account info= rmation, payment initiation, identity, and electronic signature are determi= ned based on her bank affiliation (bank identification code). In general, e= ach of these services may be provided/operated by a different entity and ex= posed at completely different endpoints (even different DNS domains).

kind regards,
Torsten.



--00000000000062d92d0571c4efac-- From nobody Tue Jul 24 22:21:08 2018 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 E8877130FBD for ; Tue, 24 Jul 2018 22:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 N-_-TwAjn3M2 for ; Tue, 24 Jul 2018 22:21:02 -0700 (PDT) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.110]) (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 9FD09130FAE for ; Tue, 24 Jul 2018 22:21:01 -0700 (PDT) Received: from [80.187.99.185] (helo=[10.154.68.6]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fiCEK-00018V-NG; Wed, 25 Jul 2018 07:20:56 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-A8156EEE-2AA9-4CBF-9AF2-F490E0895079; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Wed, 25 Jul 2018 07:20:55 +0200 Cc: oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> To: Dick Hardt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 05:21:06 -0000 --Apple-Mail-A8156EEE-2AA9-4CBF-9AF2-F490E0895079 Content-Type: multipart/alternative; boundary=Apple-Mail-BBB3184A-D57C-4211-9850-F8C554318115 Content-Transfer-Encoding: 7bit --Apple-Mail-BBB3184A-D57C-4211-9850-F8C554318115 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 24.07.2018 um 22:51 schrieb Dick Hardt : >=20 > Ok. I think I understand the use case now. Would you confirm? >=20 > These are deployed today, correct? We are building up the scheme. One banking group is deployed. >=20 > Today, a separate flow us required for each RS, correct? We support combined flows because this is a key requirement for us. But this= comes at a price: we cannot tightly audience restrict our tokens. We use ha= ndles and Introspection to ensure every RS only gets to know the data it nee= ds to know. And we must use sender constraint tokens in order to prevent tok= en leakage. Having an interoperable way to obtain structured and audience re= stricted access tokens would simply development, reduce coupling between AS &= RS and improve performance. >=20 > In the future, you would like the client to ask for multiple resources tha= t are managed by the same AS, correct? >=20 >=20 >> On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt wrote: >> For every bank (and their customers) there is a set of services run by th= e bank or other entities, which rely on the AS of the particular bank for au= thorization. In some cases, a service may bring its own AS to the party (due= to technical restrictionions). So an RP binding to a certain bank-specific s= ervice ecosystem needs to determine which AS every RS relies on. Authorizati= on requests for RS relying on the same AS (the bank) can be combined into s s= ingle request/flow resulting in an optimized UX. >>=20 >>> Am 24.07.2018 um 22:21 schrieb Dick Hardt : >>>=20 >>> I'm trying to understand the use case.=20 >>>=20 >>> It still is vague. Are you saying that each of these is run by a differe= nt entity, but all trust the bank as the authorization server to manage if t= he user has granted permission to use the resource rather than managing it t= hemselves?=20 >>>=20 >>> account information, payment initiation, identity, and electronic signat= ure=20 >>>=20 >>>> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt wrote: >>>>=20 >>>>> And who is the AS? >>>>=20 >>>> In case of yes, it=E2=80=99s typically the bank. At Deutsche Telekom, i= t is the central AS/IDP.=20 >>>>=20 >>>> Why are you asking? >>>>=20 >>>>>=20 >>>>>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt wrote: >>>>>>=20 >>>>>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt : >>>>>>>=20 >>>>>>> In your examples, are these the same AS? >>>>>>=20 >>>>>> yes >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt wrote: >>>>>>>> Hi Dick, >>>>>>>>=20 >>>>>>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt := >>>>>>>> >=20 >>>>>>>> > Entering in an email address that resolves to a resource makes se= nse. It would seem that even if this was email, calendar etc. -- that those w= ould be different scopes for the same AS, not even different resources. That= is how all of Google, Microsoft work today. >>>>>>>>=20 >>>>>>>> I don=E2=80=99t know how those services work re OAuth resources. To= me it=E2=80=99s not obvious why one should make all those services a single= OAuth resource. I assume the fact OAuth as it is specified today has no con= cept of identifying a resource and audience restrict an access token led to d= esigns not utilizing audience restriction.=20 >>>>>>>>=20 >>>>>>>> Can any of the Google or Microsoft on this list representatives ple= ase comment? >>>>>>>>=20 >>>>>>>> In deployments I=E2=80=98m familiar with email, calendar, contacts,= cloud and further services were treated as different resources and clients n= eeded different (audience restricted) access tokens to use it. >>>>>>>>=20 >>>>>>>> In case of YES, the locations of a user=E2=80=99s services for acco= unt information, payment initiation, identity, and electronic signature are d= etermined based on her bank affiliation (bank identification code). In gener= al, each of these services may be provided/operated by a different entity an= d exposed at completely different endpoints (even different DNS domains). >>>>>>>>=20 >>>>>>>> kind regards, >>>>>>>> Torsten. >>>>>=20 >>>=20 >=20 --Apple-Mail-BBB3184A-D57C-4211-9850-F8C554318115 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Am 24.07.201= 8 um 22:51 schrieb Dick Hardt <di= ck.hardt@gmail.com>:

Ok. I think I understand the use case now. Would you confi= rm?

These are deployed today, correct?

We are building up the scheme. One banking group is de= ployed.


Today, a separate flow us required for each RS, correct?
=

We support combined flows because this is a= key requirement for us. But this comes at a price: we cannot tightly audien= ce restrict our tokens. We use handles and Introspection to ensure every RS o= nly gets to know the data it needs to know. And we must use sender constrain= t tokens in order to prevent token leakage. Having an interoperable way to o= btain structured and audience restricted access tokens would simply developm= ent, reduce coupling between AS & RS and improve performance.


In the future, y= ou would like the client to ask for multiple resources that are managed by t= he same AS, correct?

On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodder= stedt <torsten@lodderstedt.net> wrote:
For every bank (and their c= ustomers) there is a set of services run by the bank or other entities, whic= h rely on the AS of the particular bank for authorization. In some cases, a s= ervice may bring its own AS to the party (due to technical restrictionions).= So an RP binding to a certain bank-specific service ecosystem needs to dete= rmine which AS every RS relies on. Authorization requests for RS relying on t= he same AS (the bank) can be combined into s single request/flow resulting i= n an optimized UX.

Am 24.07.2018 um 22:= 21 schrieb Dick Hardt <dick.hardt@gmail.com>:

I'm trying to understand the use case. 

=
It still is vague. Are you saying that each of these is run by a different entity, but= all trust the bank as the authorization server to manage if the user has gr= anted permission to use the resource rather than managing it themselves?&nbs= p;

account information, payment init= iation, identity, and electronic signature 

On Tue, Jul 24, 2018 at 8:59 AM, To= rsten Lodderstedt <torsten@lodderstedt.net> wrote:

And who is the AS?

In case of yes, it=E2=80=99s typicall= y the bank. At Deutsche Telekom, it is the central AS/IDP. 

Why are you asking?


On Mon, Jul 2= 3, 2018 at 12:50 PM, Torsten Lodderstedt <torsten@lodderstedt.net&= gt; wrote:
<= div>

Am 23.07.2018 um 13:58 schrieb Dick Hardt <= dick.hardt@gmail.c= om>:

In your examples, are these the same AS?

yes

<= div dir=3D"auto">


On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodde= rstedt <tors= ten@lodderstedt.net> wrote:
Hi= Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Entering in an email address that resolves to a resource makes sense. I= t would seem that even if this was email, calendar etc. -- that those would b= e different scopes for the same AS, not even different resources. That is ho= w all of Google, Microsoft work today.

I don=E2=80=99t know how those services work re OAuth resources. To me it=E2= =80=99s not obvious why one should make all those services a single OAuth re= source. I assume the fact OAuth as it is specified today has no concept of i= dentifying a resource and audience restrict an access token led to designs n= ot utilizing audience restriction.

Can any of the Google or Microsoft on this list representatives please comme= nt?

In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud an= d further services were treated as different resources and clients needed di= fferent (audience restricted) access tokens to use it.

In case of YES, the locations of a user=E2=80=99s services for account infor= mation, payment initiation, identity, and electronic signature are determine= d based on her bank affiliation (bank identification code). In general, each= of these services may be provided/operated by a different entity and expose= d at completely different endpoints (even different DNS domains).

kind regards,
Torsten.



= --Apple-Mail-BBB3184A-D57C-4211-9850-F8C554318115-- --Apple-Mail-A8156EEE-2AA9-4CBF-9AF2-F490E0895079 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyNTA1MjA1NVowIwYJKoZIhvcNAQkEMRYE FHrL0AYYRr937BMb/uuewr9tQOVSMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQCpx05JOZfncP1QS3j+NHKhAWLDt77x kaMSbBxs5LTXQijRNVhBzoD8cDc2EQGxXVC6u3YoG81OcW8ARHetwKERW5sUpgM6zeWxo95ElsCK dNrKFjTVoEad76gzTj1VqklJGEdeht01gWHBMUGkzlegt9oNrsXn7Pcy1OxpHa4Uu7U59CHRBudZ 52iKAehXt7/as5sMlOhk2LZfyVxDj81RFwaS69CjWM3lLsjvigqF/9zvTRh1rpO/wfXof3wDAy30 RkVDuC/VBd3XJBTXGq1KCpAaksphb989ivUpTm+kpp6fpoA0g7x9SehUscJuj5rvA4L4v/ZaTalJ MaRc+YluAAAAAAAA --Apple-Mail-A8156EEE-2AA9-4CBF-9AF2-F490E0895079-- From nobody Wed Jul 25 01:47:26 2018 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 A06EE130E51 for ; Wed, 25 Jul 2018 01:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Q6_k5-qe75uK for ; Wed, 25 Jul 2018 01:47:21 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) (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 F37B8130E4A for ; Wed, 25 Jul 2018 01:47:20 -0700 (PDT) Received: from [80.187.110.206] (helo=[10.110.206.20]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fiFS1-00067G-Sy; Wed, 25 Jul 2018 10:47:18 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-C14DF983-A490-46DF-AA87-664FDE712C8A; protocol="application/pkcs7-signature"; micalg=sha1 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Wed, 25 Jul 2018 09:22:16 +0200 Message-Id: <4EEF266D-12A7-432C-A758-BF5CE14ABEEF@lodderstedt.net> References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> Cc: oauth@ietf.org In-Reply-To: To: Dick Hardt X-Mailer: iPhone Mail (15F79) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 08:47:25 -0000 --Apple-Mail-C14DF983-A490-46DF-AA87-664FDE712C8A Content-Type: multipart/alternative; boundary=Apple-Mail-426114DA-557F-469C-B65A-20DEF9101C17 Content-Transfer-Encoding: 7bit --Apple-Mail-426114DA-557F-469C-B65A-20DEF9101C17 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >=20 > We are building up the scheme. One banking group is deployed. >=20 >>=20 >> Today, a separate flow us required for each RS, correct? >=20 > We support combined flows because this is a key requirement for us. But th= is comes at a price: we cannot tightly audience restrict our tokens. We use h= andles and Introspection to ensure every RS only gets to know the data it ne= eds to know. And we must use sender constraint tokens in order to prevent to= ken leakage. Having an interoperable way to obtain structured and audience r= estricted access tokens would simply development, reduce coupling between AS= & RS and improve performance. I forgot to mention, a deployment supporting strict resource server specific= audience restriction with structured access tokens is in place at Deutsche T= elekom for years now ( even predating OAuth 2.0). As the only drawback, enco= ding of resource servers in scopes and refresh token handling to obtain RS-s= pecific access tokens is proprietary. >=20 >>=20 >> In the future, you would like the client to ask for multiple resources th= at are managed by the same AS, correct? >>=20 >>=20 >>> On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt wrote: >>> For every bank (and their customers) there is a set of services run by t= he bank or other entities, which rely on the AS of the particular bank for a= uthorization. In some cases, a service may bring its own AS to the party (du= e to technical restrictionions). So an RP binding to a certain bank-specific= service ecosystem needs to determine which AS every RS relies on. Authoriza= tion requests for RS relying on the same AS (the bank) can be combined into s= single request/flow resulting in an optimized UX. >>>=20 >>>> Am 24.07.2018 um 22:21 schrieb Dick Hardt : >>>>=20 >>>> I'm trying to understand the use case.=20 >>>>=20 >>>> It still is vague. Are you saying that each of these is run by a differ= ent entity, but all trust the bank as the authorization server to manage if t= he user has granted permission to use the resource rather than managing it t= hemselves?=20 >>>>=20 >>>> account information, payment initiation, identity, and electronic signa= ture=20 >>>>=20 >>>>>> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt wrote: >>>>>>=20 >>>>>> And who is the AS? >>>>>=20 >>>>> In case of yes, it=E2=80=99s typically the bank. At Deutsche Telekom, i= t is the central AS/IDP.=20 >>>>>=20 >>>>> Why are you asking? >>>>>=20 >>>>>>=20 >>>>>>>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt wrote: >>>>>>>>=20 >>>>>>>=20 >>>>>>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt : >>>>>>>>=20 >>>>>>>> In your examples, are these the same AS? >>>>>>>=20 >>>>>>> yes >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt wrote: >>>>>>>>> Hi Dick, >>>>>>>>>=20 >>>>>>>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt = : >>>>>>>>> >=20 >>>>>>>>> > Entering in an email address that resolves to a resource makes s= ense. It would seem that even if this was email, calendar etc. -- that those= would be different scopes for the same AS, not even different resources. Th= at is how all of Google, Microsoft work today. >>>>>>>>>=20 >>>>>>>>> I don=E2=80=99t know how those services work re OAuth resources. T= o me it=E2=80=99s not obvious why one should make all those services a singl= e OAuth resource. I assume the fact OAuth as it is specified today has no co= ncept of identifying a resource and audience restrict an access token led to= designs not utilizing audience restriction.=20 >>>>>>>>>=20 >>>>>>>>> Can any of the Google or Microsoft on this list representatives pl= ease comment? >>>>>>>>>=20 >>>>>>>>> In deployments I=E2=80=98m familiar with email, calendar, contacts= , cloud and further services were treated as different resources and clients= needed different (audience restricted) access tokens to use it. >>>>>>>>>=20 >>>>>>>>> In case of YES, the locations of a user=E2=80=99s services for acc= ount information, payment initiation, identity, and electronic signature are= determined based on her bank affiliation (bank identification code). In gen= eral, each of these services may be provided/operated by a different entity a= nd exposed at completely different endpoints (even different DNS domains). >>>>>>>>>=20 >>>>>>>>> kind regards, >>>>>>>>> Torsten. >>>>>>=20 >>>>=20 >>=20 --Apple-Mail-426114DA-557F-469C-B65A-20DEF9101C17 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


We are building up the scheme. One banking group i= s deployed.

Today, a separate flow us required for each RS, correct?

We support combined flows because this= is a key requirement for us. But this comes at a price: we cannot tightly a= udience restrict our tokens. We use handles and Introspection to ensure ever= y RS only gets to know the data it needs to know. And we must use sender con= straint tokens in order to prevent token leakage. Having an interoperable wa= y to obtain structured and audience restricted access tokens would simply de= velopment, reduce coupling between AS & RS and improve performance.

I forgot to mention, a deployment supporting strict r= esource server specific audience restriction with structured access tokens i= s in place at Deutsche Telekom for years now ( even predating OAuth 2.0). As= the only drawback, encoding of resource servers in scopes and refresh token= handling to obtain RS-specific access tokens is proprietary.



In the future, you would like the client to ask fo= r multiple resources that are managed by the same AS, correct?

On Tu= e, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt <torsten@lodderstedt.n= et> wrote:
=
For every bank (and their customers) there is a set of servi= ces run by the bank or other entities, which rely on the AS of the particula= r bank for authorization. In some cases, a service may bring its own AS to t= he party (due to technical restrictionions). So an RP binding to a certain b= ank-specific service ecosystem needs to determine which AS every RS relies o= n. Authorization requests for RS relying on the same AS (the bank) can be co= mbined into s single request/flow resulting in an optimized UX.

Am 24.07.2018 um 22:21 schrieb Dick Hardt <dick.hardt@gmail.com>:


In case of yes, it=E2=80=99s typically the bank. At Deutsche Telekom= , it is the central AS/IDP. 

Why are you asking?


On Mon, Jul 23, 2018 at 12:50 PM, Torsten L= odderstedt <torsten@lodderstedt.net> wrote:

A= m 23.07.2018 um 13:58 schrieb Dick Hardt <dick.hardt@gmail.com>:

In your examples, are these t= he same AS?

yes



O= n Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrot= e:
Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Entering in an email address that resolves to a resource makes sense. I= t would seem that even if this was email, calendar etc. -- that those would b= e different scopes for the same AS, not even different resources. That is ho= w all of Google, Microsoft work today.

I don=E2=80=99t know how those services work re OAuth resources. To me it=E2= =80=99s not obvious why one should make all those services a single OAuth re= source. I assume the fact OAuth as it is specified today has no concept of i= dentifying a resource and audience restrict an access token led to designs n= ot utilizing audience restriction.

Can any of the Google or Microsoft on this list representatives please comme= nt?

In deployments I=E2=80=98m familiar with email, calendar, contacts, cloud an= d further services were treated as different resources and clients needed di= fferent (audience restricted) access tokens to use it.

In case of YES, the locations of a user=E2=80=99s services for account infor= mation, payment initiation, identity, and electronic signature are determine= d based on her bank affiliation (bank identification code). In general, each= of these services may be provided/operated by a different entity and expose= d at completely different endpoints (even different DNS domains).

kind regards,
Torsten.



= --Apple-Mail-426114DA-557F-469C-B65A-20DEF9101C17-- --Apple-Mail-C14DF983-A490-46DF-AA87-664FDE712C8A Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyNTA3MjIxN1owIwYJKoZIhvcNAQkEMRYE FF8dXu/DLYQpMy+pfSqJj2yZlJ83MIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQCPeoDaa2EIpwNJi2fwmYo5SZf6C41H hXD5GUy90mrYaAbTAMkptPi3UYkQC2/qpTAMya5s0kwIF/olsyft6Xzc6htV8RZG5Zy2MmnQT3jY 9IBDxw1k8TNu85WSkXQzzT1fB04Qv71PS5SWPif8z09rpMKpo3z/iSIK4gZLu7U7k6F3vZMGyWHO CQtdlru/ren9VaHfdJSQk/iQ8/7lg3qgszmhKooQbxg+2g941+GIOVfg7WZQyjEoWx43jNHhmgej mudtPp3gL84m8DwO9RewdxWriWfjFPurxwFOUrXMswYZCS/RPJYsyvXwQBCWZ3DUZ1WLQDxL8WMb eVQw4dX/AAAAAAAA --Apple-Mail-C14DF983-A490-46DF-AA87-664FDE712C8A-- From nobody Sun Jul 29 09:26:12 2018 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 8E593130E01; Sun, 29 Jul 2018 09:26:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153288156357.7132.7206843681571127621.idtracker@ietfa.amsl.com> Date: Sun, 29 Jul 2018 09:26:03 -0700 Archived-At: Subject: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 16:26:04 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-oauth-device-flow-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is generally a fine document and it was easy to follow. I am agreeing with Benjamin's DISCUSS about amount of entropy in codes. In addition, the last para in Section 6.1 reads: The server should ignore any characters like punctuation that are not in the user-code character set. Provided that the character set doesn't include characters of different case, the comparison should be case insensitive. This makes me uncomfortable, because you are talking of case-insensitivity, without fully specifying what it is. I assume that your advice only applies to user-code character sets which only use subset of ASCII? Because if you mean to extend your advice to full Unicode, you need more text and references here. Can you please clarify. From nobody Mon Jul 30 22:30:26 2018 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 5F88B129385; Mon, 30 Jul 2018 22:30:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153301502438.7978.5847796028555208466.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2018 22:30:24 -0700 Archived-At: Subject: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 05:30:24 -0000 Adam Roach has entered the following ballot position for draft-ietf-oauth-device-flow-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. I have a couple of related issues that need to be cleared up before publication, but I expect that these should be easy to resolve. §3.1: > The client initiates the flow by requesting a set of verification > codes from the authorization server by making an HTTP "POST" request > to the device authorization endpoint. The client constructs the > request with the following parameters, encoded with the "application/ > x-www-form-urlencoded" content type: This document needs a normative citation for this media type. My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as this appears to be the most recent stable description of how to encode this media type. I'd love to hear rationale behind other citations being more appropriate, since I'm not entirely happy with the one I suggest above (given that it's been superseded by HTML 5.2); but every other plausible citation I can find is even less palatable (with HTML 5.2 itself having the drawback of not actually defining how to encode the media type, instead pointing to an unstable, unversioned document). (Non-discuss comment: this passage could be made clearer by saying something like "...parameters, sent as the body of the request, encoded with the...") --------------------------------------------------------------------------- §3.2: > In response, the authorization server generates a device verification > code and an end-user code that are valid for a limited time and > includes them in the HTTP response body using the "application/json" > format with a 200 (OK) status code. This needs to normatively cite RFC 7159. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §3.5: > slow_down > The client is polling too quickly and should back off at a > reasonable rate. I'm surprised the document doesn't define what is meant by "reasonable rate" here. I would expect to see something concrete like "the client should double the interval between polling requests" or some similarly concrete advice. > If no interval was provided, the client > MUST use a reasonable default polling interval. Similarly, I'm really sad that this does not give concrete guidance for what "reasonable" might be. Implementations may well decide 100ms is "reasonable" for the purpose of application responsiveness -- but I suspect average OAuth servers wouldn't be happy with that. This would be a DISCUSS, but I see that Mirja has already registered a DISCUSS on this topic. I support her DISCUSS. --------------------------------------------------------------------------- §6.1: This section discusses code input by the user. I'm surprised that it doesn't also discuss confusability considerations (e.g., I, l, and 1; 0 and O) =========================================================================== All of my remaining comments are minor editorial nits. --------------------------------------------------------------------------- Abstract: > This OAuth 2.0 authorization flow for browserless and input > constrained devices Nit: "...input-constrained..." > 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 is a very long and winding sentence. Consider breaking up into multiple sentences. --------------------------------------------------------------------------- §1: > This OAuth 2.0 protocol flow for browserless and input constrained Nit: "...input-constrained..." Please cite RFC 6749 here. --------------------------------------------------------------------------- §1: > The only requirements to use this flow are that the device is > connected to the Internet, and able to make outbound HTTPS requests, > be able to display or otherwise communicate a URI and code sequence > to the user, and that the user has a secondary device (e.g., personal > computer or smartphone) from which to process the request. This is hard to read, and difficult to pack into one sentence (due to the requirements being on both the device and its user). Consider reworking into a bulleted list; e.g.: The only requirements to use this flow are: * The device is connected to the Internet * The device is able to make outbound HTTPS requests * The device is able to display or otherwise communicate a URI and code sequence to the user * The user has a secondary device (e.g., personal computer or smartphone) from which they can process the request --------------------------------------------------------------------------- §1: > Instead of interacting with the end-user's user-agent, the client Nit: "...end user's user agent..." > instructs the end-user to use another computer or device and connect Nit: "...end user..." --------------------------------------------------------------------------- §1: > (C) The client instructs the end-user to use its user-agent Nit: "...end user..." Nit: "...user agent..." > client provides the end-user with the end-user code to enter in Nit: "...provides the end user with the end-user code..." --------------------------------------------------------------------------- §1: > (D) The authorization server authenticates the end-user (via the "...the end user..." > user-agent) and prompts the end-user to grant the client's access "...user agent... end user..." > request. If the end-user agrees to the client's access request, "...the end user..." > the end-user enters the end-user code provided by the client. The "...the end user enters the end-user code..." > authorization server validates the end-user code provided by the > end-user. "...by the end user." --------------------------------------------------------------------------- §1: > (E) While the end-user authorizes (or denies) the client's request "...the end user..." > (step D), the client repeatedly polls the authorization server to > find out if the end-user completed the end-user authorization "...the end user completed the end-user authorization..." --------------------------------------------------------------------------- §1: > (F) Assuming the end-user granted access, the authorization server "...the end user..." --------------------------------------------------------------------------- §2: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. Consider updating to use the boilerplate specified in RFC 8174. --------------------------------------------------------------------------- §2: > End-User Verification Code: > A short-lived token which the device displays to the end user, is > entered by the end-user on the authorization server, and is thus "...end user..." > used to bind the device to the end-user. "...end user..." --------------------------------------------------------------------------- §3.3: > session. The authorization server prompts the end-user to identify "...end user..." --------------------------------------------------------------------------- §5.1: > In some applications this > attack may not make much economic sense, for example for a video app, > the owner of the device may then be able to purchase movies with the > attacker's account, however there are still privacy considerations in > that case as well as other uses of the device flow whereby the > granting account may be able to perform sensitive actions such as > controlling the victim's device. This is a run-on sentence. Restructure by replacing the commas after "sense" and "account" with either semicolons or periods. --------------------------------------------------------------------------- §5.2: > malicious, then it could man-in-the middle the backchannel flow to "...man-in-the-middle..." > middle is not completely hidden from sight, as the end-user would end "...end user..." From nobody Mon Jul 30 23:17:24 2018 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 B06DA130DC0; Mon, 30 Jul 2018 23:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 a0R7VWRM37Bo; Mon, 30 Jul 2018 23:17:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9C9FE130934; Mon, 30 Jul 2018 23:17:19 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6V6HFia036226 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 31 Jul 2018 01:17:15 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local From: Adam Roach To: The IESG Cc: oauth@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-device-flow@ietf.org, rifaat.ietf@gmail.com References: <153301502438.7978.5847796028555208466.idtracker@ietfa.amsl.com> Message-ID: <8491735a-6fcc-8970-9d4f-5e41b3c8aa9f@nostrum.com> Date: Tue, 31 Jul 2018 01:17:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153301502438.7978.5847796028555208466.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------43B5C22E6C8C947D007F3FDD" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 06:17:22 -0000 This is a multi-part message in MIME format. --------------43B5C22E6C8C947D007F3FDD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/31/18 12:30 AM, Adam Roach wrote: > §3.2: > >> In response, the authorization server generates a device verification >> code and an end-user code that are valid for a limited time and >> includes them in the HTTP response body using the "application/json" >> format with a 200 (OK) status code. > This needs to normatively cite RFC 7159. Thanks to Carsten for reminding me that this has been replaced by RFC 8259. Sorry for confusing things. /a --------------43B5C22E6C8C947D007F3FDD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/31/18 12:30 AM, Adam Roach wrote:
§3.2:


 In response, the authorization server generates a device verification
 code and an end-user code that are valid for a limited time and
 includes them in the HTTP response body using the "application/json"
 format with a 200 (OK) status code.

This needs to normatively cite RFC 7159.


Thanks to Carsten for reminding me that this has been replaced by RFC 8259. Sorry for confusing things.

/a

--------------43B5C22E6C8C947D007F3FDD-- From nobody Tue Jul 31 08:58:20 2018 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 33BFE130EF4; Tue, 31 Jul 2018 08:58:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-oauth-device-flow@ietf.org, Rifaat Shekh-Yusef , oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153305269020.3071.5881779499900104302.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2018 08:58:10 -0700 Archived-At: Subject: [OAUTH-WG] Alissa Cooper's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 15:58:11 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-oauth-device-flow-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Mirja's DISCUSS point #3 which was also raised by the Gen-ART reviewer. The Gen-ART review also included a number of other useful comments. Please address them. Perhaps this is implicit, but I found it a little odd that there is no mention of whether the device codes and user codes are expected to be unique to individual devices. Section 3.3: "It is NOT RECOMMENDED for authorization servers to include the user code in the verification URI ("verification_uri"), as this increases the length and complexity of the URI that the user must type." I don't fully understand the justification for the normative requirement here. The user ultimately ends up typing in both strings, right? Is it so much more complex to type them both into a browser bar contiguously than to type the uri into the browser bar and the code into some form field on the page such that the normative requirement is warranted? Section 3.3.1: Wouldn't there be textual instructions about how to use the QR code also included here? If the point is to illustrate the UI it seems like those should be included too. From nobody Tue Jul 31 08:58:48 2018 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 A909D126F72; Tue, 31 Jul 2018 08:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=oCx06RQY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cBo36DdD 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 S1L92qBZRGSD; Tue, 31 Jul 2018 08:58:44 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3961130F0A; Tue, 31 Jul 2018 08:58:44 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 94F3121D45; Tue, 31 Jul 2018 11:58:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 31 Jul 2018 11:58:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=9R11wHfhqtj2GK0kkq/WqaStD48rw Rgc5BkK6SATf7A=; b=oCx06RQYw5MD+zCCEWo/RCCWP34GlL/P5EEbYbv7xMUzH uTyidFbVBIZYapyG2kcUlXpbquKF5ZcYybB+qnufOKdRLoyRtWjQUk3D6DDocnnA N9xIhAMNq1qBfGVqKhIyRp+M2IT462e7KRw7PALtDjwLYQjAnZUoW8D6xtRBmubB 8jFdfCqkHDcOfSf5pSPZ7dtbB6YSga3He9qMQb4Hs3JiiFzxZovXK+BpLLQOKHI2 pJPDBUJ64xwkCArOot2Z2C7Pe2A9NHdyYp0HP9XSAtReo8yKTmotUdetnDJa314P 81rCfpTSUorOB/9OzkYro4G/hQFsnZ28RE6yZpXcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9R11wH fhqtj2GK0kkq/WqaStD48rwRgc5BkK6SATf7A=; b=cBo36DdDQE9USqtQCjF5T/ 76YwuWT3qcn0BBCFpvD+OwszajtDrBxD9kgGUiVo0F4A6kKslIQ0HCU1UH6JLtjC +WVQPw/C7KZdCGlOWCsNpqjy1AtvR4yhC2u1nuaXBU86yjFJOmVPIT8jy23rY78+ XnhN1UUCvwYHIyI/4BycHNLfRJalnJ+plaYFKuYguiPD3sSpTlwRFz2K7EX3AOVZ 9Vzx+hLD9MvKCU54NSqz7mjGyhU+D/GVlSw3CSEd8UUi5/g2gyzWyeHqp0dnkpIV 7v5NDgmChHMckYxEMZHwWA0oc0aDolFRhulVqNo2Ch8TouhPRrjPkr8XihZjfQ/w == X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id A17A8E455F; Tue, 31 Jul 2018 11:58:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Tue, 31 Jul 2018 11:58:41 -0400 Cc: General Area Review Team , draft-ietf-oauth-device-flow.all@ietf.org, oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152873404689.2672.12557627140070509936@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OAUTH-WG] [Gen-art] Genart last call review of draft-ietf-oauth-device-flow-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 15:58:47 -0000 Robert, thanks for your review. I have pointed to it in my No Objection = ballot. Alissa > On Jul 20, 2018, at 1:37 PM, Robert Sparks = wrote: >=20 > As far as I can tell, there has been no response to this. The document = revision just updated a reference to reflect an rfc having been = published. >=20 > Apologies if I missed a response. >=20 > RjS >=20 >=20 > On 6/11/18 12:20 PM, Robert Sparks wrote: >> Reviewer: Robert Sparks >> Review result: Ready with Nits >>=20 >> 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. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-oauth-device-flow-10 >> Reviewer: Robert Sparks >> Review Date: 2018-06-11 >> IETF LC End Date: 2018-06-12 >> IESG Telechat date: Not scheduled for a telechat >>=20 >> Summary: Ready for publication as a Proposed Standard RFC, but with = nits to >> consider >>=20 >> Nits/editorial comments: >>=20 >> In 3.5 "the client MUST use a reasonable default polling interval" is = not >> testable. Who determines "reasonable"? At the very least, you should = add some >> text about how to determine what "reasonable" is for a given device, = and add >> some text that says don't poll faster than earlier responses limited = you to. >> For example, if the response at step B in the introductory diagram = had an >> explicit interval of 15, but a slow-down response to an E message = didn't have >> an explicit interval, you don't want them to default to, say 5 = seconds (because >> that's what the example in section 3.2 said, so it must be = reasonable). >>=20 >> In 3.3, you say the device_code MUST NOT be displayed or = communicated. Is there >> a security property that's lost if there is? Or is this just saying = "Don't >> waste space or the user's time"? >>=20 >> The last paragraph of section 6.1 feels like a recipe for false = positives, and >> for bug-entrenched code. Please reconsider it. >>=20 >> You need line-folding in the example in section 3.2 >>=20 >>=20 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jul 31 09:07:11 2018 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 54CE0130DD9 for ; Tue, 31 Jul 2018 09:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.61 X-Spam-Level: X-Spam-Status: No, score=-15.61 tagged_above=-999 required=5 tests=[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, T_DKIMWL_WL_MED=-0.01, 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 7ApO4L9dFVk5 for ; Tue, 31 Jul 2018 09:07:02 -0700 (PDT) Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (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 3B2DA130E35 for ; Tue, 31 Jul 2018 09:07:00 -0700 (PDT) Received: by mail-ua0-x244.google.com with SMTP id g18-v6so10633830uam.6 for ; Tue, 31 Jul 2018 09:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MR7ePojU1jZPeHSe3+23Pr4XUEbGzgzlyJevr3CmgtY=; b=LLwG3ie8RS17CAPEBj/1DrNM35ep1+Zd1RoCAmLIDdOv2wRrk9c95DSgjNKVud8fVy kLVujns8O0y5r8u10sHlmdnZEw+fyQfBKgcbod/g6VXqU3KkaBGxo1HZZWfN6fmbxoHB xMAr/UkdKlSdde74u5oflPEh8JN9sPwUd77ABUtubhN1ZUJA6BeWQ68XJHDxN2Ozlqcf MmSE1el+cBLH68YaUMK7kHNdYz3i8xI0+wIXdSsNP4Txug7Op5ILw88+hDmJQHEECIEy Wi2upC2TQahtslY55UUtTyU4gYKkL0FV695e8T6yVUnuwJUOAs2GBVurkxTqhO1cammC Y9iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MR7ePojU1jZPeHSe3+23Pr4XUEbGzgzlyJevr3CmgtY=; b=r1uFBMuvEkV7Dvd7q0baW2OICQ6FPVQCKu5+MzKb0u5bCKqhez3xmkS3L4DEPefK7J dE6I+NzRstlb9eojwBuemusXzd9xZ6idIdb5AOgh/GtdIiM6uGCZs+tPoTbgxmcRlw8V AW51vAMRR5hNF9M+lZ5PgDGs8s2JmVaF9MomVA3BBEQHVhLt7nN3whIQv44V1rZV5u8+ FF+yVTgqAn+sQd9PZ7mb7chBg2QhSgrKlpuVXD3zfUGsOxc8uB9qPxyT5LCQgiLk5kPE gHvPMAm16mKr6/j9QkRSH8wn2enB8a0lrNhIiA5oPA8QxXC2ay5erxKeL1M2mckQ+Y4g 58Fg== X-Gm-Message-State: AOUpUlFHxUcRmkQuA0R6XePQBNWDqjbiw1oqdTwiQ+afNZgIurY/FsNq YiOAg8UE2ZYlhY43lddNpxLBNI7Drcf6mSu0Khe0UQ== X-Google-Smtp-Source: AAOMgpdmGUHtjX/Ug6kaLO1oCtRPCEw2sadeHfIuCZVIHXb5qmD8pkB2LMUeBKr3Td5Iy8QcsZL33WMO5wDxHTXeRb4= X-Received: by 2002:ab0:4987:: with SMTP id e7-v6mr15859373uad.198.1533053218673; Tue, 31 Jul 2018 09:06:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:185a:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 09:06:38 -0700 (PDT) In-Reply-To: References: <152873404689.2672.12557627140070509936@ietfa.amsl.com> From: William Denniss Date: Tue, 31 Jul 2018 09:06:38 -0700 Message-ID: To: Alissa Cooper Cc: Robert Sparks , General Area Review Team , draft-ietf-oauth-device-flow.all@ietf.org, oauth Content-Type: multipart/alternative; boundary="00000000000085dcaa05724dc42d" Archived-At: Subject: Re: [OAUTH-WG] [Gen-art] Genart last call review of draft-ietf-oauth-device-flow-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 16:07:05 -0000 --00000000000085dcaa05724dc42d Content-Type: text/plain; charset="UTF-8" Thank you Robert, and Alissa, we really appreciate you feedback. My co-authors and I are processing yours and all the feedback received so far. We'll reply to your points in the coming days. On Tue, Jul 31, 2018 at 8:58 AM, Alissa Cooper wrote: > Robert, thanks for your review. I have pointed to it in my No Objection > ballot. > > Alissa > > > On Jul 20, 2018, at 1:37 PM, Robert Sparks wrote: > > > > As far as I can tell, there has been no response to this. The document > revision just updated a reference to reflect an rfc having been published. > > > > Apologies if I missed a response. > > > > RjS > > > > > > On 6/11/18 12:20 PM, Robert Sparks wrote: > >> Reviewer: Robert Sparks > >> Review result: Ready with Nits > >> > >> 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-device-flow-10 > >> Reviewer: Robert Sparks > >> Review Date: 2018-06-11 > >> IETF LC End Date: 2018-06-12 > >> IESG Telechat date: Not scheduled for a telechat > >> > >> Summary: Ready for publication as a Proposed Standard RFC, but with > nits to > >> consider > >> > >> Nits/editorial comments: > >> > >> In 3.5 "the client MUST use a reasonable default polling interval" is > not > >> testable. Who determines "reasonable"? At the very least, you should > add some > >> text about how to determine what "reasonable" is for a given device, > and add > >> some text that says don't poll faster than earlier responses limited > you to. > >> For example, if the response at step B in the introductory diagram had > an > >> explicit interval of 15, but a slow-down response to an E message > didn't have > >> an explicit interval, you don't want them to default to, say 5 seconds > (because > >> that's what the example in section 3.2 said, so it must be reasonable). > >> > >> In 3.3, you say the device_code MUST NOT be displayed or communicated. > Is there > >> a security property that's lost if there is? Or is this just saying > "Don't > >> waste space or the user's time"? > >> > >> The last paragraph of section 6.1 feels like a recipe for false > positives, and > >> for bug-entrenched code. Please reconsider it. > >> > >> You need line-folding in the example in section 3.2 > >> > >> > >> _______________________________________________ > >> Gen-art mailing list > >> Gen-art@ietf.org > >> https://www.ietf.org/mailman/listinfo/gen-art > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art > > --00000000000085dcaa05724dc42d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Robert, and Alissa, we really appreciate you fee= dback. My co-authors and I are processing yours and all the feedback receiv= ed so far. We'll reply to your points in the coming days.


On Tue, Ju= l 31, 2018 at 8:58 AM, Alissa Cooper <alissa@cooperw.in> wro= te:
Robert, thanks for your review. I hav= e pointed to it in my No Objection ballot.

Alissa

> On Jul 20, 2018, at 1:37 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
>
> As far as I can tell, there has been no response to this. The document= revision just updated a reference to reflect an rfc having been published.=
>
> Apologies if I missed a response.
>
> RjS
>
>
> On 6/11/18 12:20 PM, Robert Sparks wrote:
>> Reviewer: Robert Sparks
>> Review result: Ready with Nits
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Are= a
>> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair.=C2=A0 Please treat these comments = just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/= GenArtfaq>.
>>
>> Document: draft-ietf-oauth-device-flow-10
>> Reviewer: Robert Sparks
>> Review Date: 2018-06-11
>> IETF LC End Date: 2018-06-12
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary: Ready for publication as a Proposed Standard RFC, but wit= h nits to
>> consider
>>
>> Nits/editorial comments:
>>
>> In 3.5 "the client MUST use a reasonable default polling inte= rval" is not
>> testable. Who determines "reasonable"? At the very least= , you should add some
>> text about how to determine what "reasonable" is for a g= iven device, and add
>> some text that says don't poll faster than earlier responses l= imited you to.
>> For example, if the response at step B in the introductory diagram= had an
>> explicit interval of 15, but a slow-down response to an E message = didn't have
>> an explicit interval, you don't want them to default to, say 5= seconds (because
>> that's what the example in section 3.2 said, so it must be rea= sonable).
>>
>> In 3.3, you say the device_code MUST NOT be displayed or communica= ted. Is there
>> a security property that's lost if there is? Or is this just s= aying "Don't
>> waste space or the user's time"?
>>
>> The last paragraph of section 6.1 feels like a recipe for false po= sitives, and
>> for bug-entrenched code. Please reconsider it.
>>
>> You need line-folding in the example in section 3.2
>>
>>
>> _______________________________________________
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen= -art
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art=


--00000000000085dcaa05724dc42d-- From nobody Tue Jul 31 23:21:19 2018 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 53D3C130FB2; Tue, 31 Jul 2018 23:21:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Zitao Wang To: Cc: draft-ietf-oauth-token-exchange.all@ietf.org, ietf@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153310447029.3248.454015280311920642@ietfa.amsl.com> Date: Tue, 31 Jul 2018 23:21:10 -0700 Archived-At: Subject: [OAUTH-WG] Opsdir last call review of draft-ietf-oauth-token-exchange-14 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 06:21:10 -0000 Reviewer: Zitao Wang Review result: Ready I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-oauth-token-exchange-14 Summary: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.


If we want to have audience constrained access tokens, then it is s= afer to have only one resource in the access token - otherwise each resource= can use the access token to access the other resources.

Yes and no. Yes because it=E2=80=99s safer to use t= ightly audience restricted access tokens.

No becaus= e token binding or cert-bound access tokens can prevent abuse in such a case= .


All of these examples assume that it is a single AS. Supporting mult= iple AS in a single request seems super complicated and wrought with securit= y and trust issues.

I don=E2=80= =99t see a use case for multiple AS (yet ;-).

kind r= egards,
Torsten.




On Fri, Jul 20, 2018 at 11:13 AM, Mike Jo= nes <Michael.Jones=3D40microsoft.com@dmarc.ietf= .org> wrote:

While I agree that a si= ngle requested resource is the common case, enough people have spoken up wit= h a need for multiple requested resources over the years that I think everyo= ne will be better served by leaving the ability to specify multiple requested resources in the specification.

 

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

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of= Brian Campbell
Sent: Friday, July 20, 2018 10:18 AM
To: Filip Skokan <panva.ip@gmail.com>


Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators fo= r OAuth 2.0"

 

The current draft does allow multiple "resource" para= meters. However, there seemed to be consensus in the WG meeting yesterday th= at only a single "resource" parameter was preferable and that a client could= obtain an access token per resource (likely using a refresh token). I'm personally sympathetic to that point. B= ut maybe it's too restrictive. I would like to see some more text about the c= omplexity implications of multiple "resource" parameters and perhaps some di= scouragement of doing so. I believe logical names are more potentially useful in an STS framework like t= oken exchange but should be out of scope for this work.  

 

 

 

 

 

 

 

On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan <panva.ip@gmail.com&g= t; wrote:

Hi Torsten,

 

> Multiple "resource" parameters may be used t= o indicate that the issued token is intended to be used at multiple resource= servers.

 

That's already in. Furthermore what about logical nam= es for target services? Like was added in -03 of token exchange?


Best,
Filip Skokan

 

 

On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt &= lt;torsten@lodd= erstedt.net> wrote:

I support adoption of this document.

 

I would like to point out (again) a single resource i= s not sufficient for most use cases I implemented in the last couple if year= s. I=E2=80=98m advocating for enhancing the draft to support multiple resour= ces and a clear definition of the relationship between resource(s) and scope.


Am 20.07.2018 um 08:20 schrieb n-sakimura <n-sakimura@nri.co.jp>:

+1

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: oauth <oau= th@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators fo= r OAuth 2.0"

 

I support adoption of this document.

 

On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef &= lt;rifaat.ietf@gm= ail.com> wrote:

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0' doc= ument
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indi= cators-02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat


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

 


CONFIDENTIALIT= Y NOTICE: This email may contain confidential and privileged material for th= e 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 th= e sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.

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

_______________________________________________<= br> 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

 


CONFIDENTIALIT= Y NOTICE: This email may contain confidential and privileged material for th= e 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 th= e sender immediately by e-mail and delete the message and any file attachmen= ts 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/mai= lman/listinfo/oauth
= --Apple-Mail-3681D98F-F012-4B30-BFB2-586B0569A6E6-- --Apple-Mail-647604C8-5B33-4C22-9498-E9776A27D3FB Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDcyMTE2NDAwOVow IwYJKoZIhvcNAQkEMRYEFBfuQG8SjpTmPz+hOrRBAPVFPOoUMIG+BgkrBgEEAYI3EAQxgbAwga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQBOZxHflXQy+ZqgYqqA WPNNacObyFKU1+vQAvebl51LEGlc3n/HpUhtr+jmrYnUFHJR5XCcpqDMnblD+r4HPX12/I6gG5ar YXkfQzdywIH91bzz79gPYJvSARCyIi+cIVm88ZcQtk4mUjUr8BUyW/SNJavem3BXeik5o66fjORg /wSdeipvTIUI8IASVGnAIz166FdFEpb3BUR+dIh/2reYmaII/CFqG7crtF7ksG8+W6Je9O79DuNv WQ/xddlLgE4eeV/CAacbfZmBK4mLiW+w7e3+UMTQINkTRiTUNSlt1pN4sBIsIdV4Yd8mkHceRNQ7 5xmbn8CkYHHs1jIQnhuQAAAAAAAA --Apple-Mail-647604C8-5B33-4C22-9498-E9776A27D3FB-- From nobody Sat Jul 21 09:49:13 2018 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 5F012130DC4 for ; Sat, 21 Jul 2018 09:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MP8OyvA-syQX for ; Sat, 21 Jul 2018 09:49:09 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (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 2560A127333 for ; Sat, 21 Jul 2018 09:49:09 -0700 (PDT) Received: from [80.187.120.149] (helo=[10.150.89.103]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fgv47-0000Kn-0U; Sat, 21 Jul 2018 18:49:07 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-E12ECF2A-90C9-487C-BF96-94BC9F394B69; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (15F79) In-Reply-To: Date: Sat, 21 Jul 2018 18:49:05 +0200 Cc: oauth@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> References: <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> To: Dick Hardt X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 16:49:12 -0000 --Apple-Mail-E12ECF2A-90C9-487C-BF96-94BC9F394B69 Content-Type: multipart/alternative; boundary=Apple-Mail-AA44DDF2-264D-4562-8CD5-3F3A7A6A046F Content-Transfer-Encoding: 7bit --Apple-Mail-AA44DDF2-264D-4562-8CD5-3F3A7A6A046F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dick, Am 19.07.2018 um 15:46 schrieb Dick Hardt : >> I think any scenario with multiple resource servers relying on the same A= S for authorization where the client acts on behalf of the resource owner qu= alifies for grant type code and distributed OAuth.=20 >>=20 >> Let=E2=80=99s assume a user wants to authorize a client for access to her= cloud storage, email account and contacts when setting app the respective a= pp. >=20 > Would you walk me through the user experience that happened for the client= to do discovery on these three resources? In other words, what did the user= do to get the client to call the resource and get back the 401 response? I would assume the user enters the URLs or identifies the respective service= providers in the app (e.g. by entering her email address). The client then s= ends an initial request as described in your draft and gets back the 401. Doing so for several resources will give the client the AS URL for all invol= ved resources. If the client compares the iss claims it will figure our all r= esources are protected by the same AS and can authorize access via a single a= uthz code grant flow. kind regards, Torsten.= --Apple-Mail-AA44DDF2-264D-4562-8CD5-3F3A7A6A046F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Dick,

Am 1= 9.07.2018 um 15:46 schrieb Dick Hardt <dick.hardt@gmail.com>:

<= div>
I think any scenario wit= h multiple resource servers relying on the same AS for authorization where t= he client acts on behalf of the resource owner qualifies for grant type code= and distributed OAuth. 

Let=E2=80=99s assume a user= wants to authorize a client for access to her cloud storage, email account a= nd contacts when setting app the respective app.

= = Rob Otto =
= EMEA Field CTO/Solutions Architect =
= robertotto@pingidenti= ty.com =
= =
= = c: +44 (0) 777 135 6= 092 =
=
=
Conn= ect with us: = 3D"Glassdoor = 3D"LinkedIn = = = 3D"youtube= = 3D"Google+ = 3D"Blog= =